From bertietf@bwijnen.net Sun Nov 1 13:00:36 2009 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6E3273A68B4 for ; Sun, 1 Nov 2009 13:00:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.309 X-Spam-Level: * X-Spam-Status: No, score=1.309 tagged_above=-999 required=5 tests=[AWL=-0.849, BAYES_50=0.001, HELO_MISMATCH_NET=0.611, HOST_EQ_NL=1.545, HTML_MESSAGE=0.001] 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 r3PIQrMHwOA6 for ; Sun, 1 Nov 2009 13:00:35 -0800 (PST) Received: from relay.versatel.net (relay56.tele2.vuurwerk.nl [62.250.3.56]) by core3.amsl.com (Postfix) with ESMTP id 69A023A67F4 for ; Sun, 1 Nov 2009 13:00:33 -0800 (PST) Received: from [87.215.199.34] (helo=BertLaptop) by relay.versatel.net with smtp (Exim 4.69) (envelope-from ) id 1N4hXe-0003NI-M0 for netconf@ietf.org; Sun, 01 Nov 2009 22:00:50 +0100 Message-ID: <29C90FF62F4F4BE1ADE798A521C0284C@BertLaptop> From: "Bert Wijnen \(IETF\)" To: "Netconf" Date: Sun, 1 Nov 2009 22:00:29 +0100 Organization: Consultant MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_1EBE_01CA5B3E.B9ADDE40" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Windows Mail 6.0.6002.18005 X-MimeOLE: Produced By Microsoft MimeOLE V6.0.6002.18005 Subject: [Netconf] Fw: Pre-posting of slides in Hiroshima X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Nov 2009 21:00:36 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_1EBE_01CA5B3E.B9ADDE40 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable WG participants, for those of you who are planning to display/use slides for our = Hiroshima session, please consider the below! Bert and Mehmet ----- Original Message -----=20 From: Adrian Farrel=20 Sent: Saturday, October 31, 2009 9:25 PM Subject: Pre-posting of slides in Hiroshima Hi, We can expect a higher than normal number of people at our WG meetings = in=20 Hiroshima for whom English is not the first language. In discussions in Stockholm, the thing that Asian participants said = would be=20 most useful was pre-posting of the slides. This allows them to look up = any=20 difficult words, make notes, and follow along at their own speed. I know many working groups have a good record of posting slides before = their=20 meetings. Can I ask you all to make a special effort to get the material = onto the IETF site ahead of your meetings (preferably at least a day = ahead)=20 as an act of courtesy and to ensure better discussions within your = working=20 groups. Thanks, Adrian=20 ------=_NextPart_000_1EBE_01CA5B3E.B9ADDE40 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
WG participants,
 
for those of you who are planning to display/use = slides for=20 our Hiroshima session,
please consider the below!
 
Bert and Mehmet
 
----- Original Message -----=20
From: Adrian = Farrel=20
Sent: Saturday, October 31, 2009 9:25 PM
Subject: Pre-posting of slides in Hiroshima

Hi,

We can expect a higher than normal number of = people at=20 our WG meetings in
Hiroshima for whom English is not the first=20 language.

In discussions in Stockholm, the thing that Asian = participants=20 said would be
most useful was pre-posting of the slides. This allows = them to=20 look up any
difficult words, make notes, and follow along at their = own=20 speed.

I know many working groups have a good record of posting = slides=20 before their
meetings. Can I ask you all to make a special effort to = get the=20 material
onto the IETF site ahead of your meetings (preferably at = least a=20 day ahead)
as an act of courtesy and to ensure better discussions = within=20 your working
groups.

Thanks,
Adrian
------=_NextPart_000_1EBE_01CA5B3E.B9ADDE40-- From mehmet.ersue@nsn.com Mon Nov 2 02:58:18 2009 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A247F3A67C2 for ; Mon, 2 Nov 2009 02:58:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001] 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 ASJmoQSYjZD7 for ; Mon, 2 Nov 2009 02:58:17 -0800 (PST) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [93.183.12.31]) by core3.amsl.com (Postfix) with ESMTP id F37CA3A68D1 for ; Mon, 2 Nov 2009 02:58:16 -0800 (PST) Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id nA2AwU7O002090 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 2 Nov 2009 11:58:30 +0100 Received: from demuexc024.nsn-intra.net (demuexc024.nsn-intra.net [10.159.32.11]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id nA2AwUJv003732; Mon, 2 Nov 2009 11:58:30 +0100 Received: from DEMUEXC006.nsn-intra.net ([10.150.128.18]) by demuexc024.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Mon, 2 Nov 2009 11:58:30 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CA5BAB.69434EC8" Date: Mon, 2 Nov 2009 11:58:27 +0100 Message-ID: <80A0822C5E9A4440A5117C2F4CD36A640E0D40@DEMUEXC006.nsn-intra.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Agenda for IETF #76 NETCONF Session Thread-Index: Acpbq2gAheLQEOYmSHC0oWa4FnJyjQ== From: "Ersue, Mehmet (NSN - DE/Munich)" To: X-OriginalArrivalTime: 02 Nov 2009 10:58:30.0104 (UTC) FILETIME=[69806D80:01CA5BAB] Subject: [Netconf] Agenda for IETF #76 NETCONF Session X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Nov 2009 10:58:18 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CA5BAB.69434EC8 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi All,=20 please find below the agenda we prepared for the=20 NETCONF WG session at the IETF #76. Our session will=20 be on MONDAY, November 9, 2009, 1520-1720. =20 Our main focus in the session will be as usual on open=20 issue discussion. Please send us your comments and=20 any additional topics you have for discussion.=20 IETF secretary kindly organized a Webex+Conference=20 setup for us so WG members can also participate remotely. Presenters please confirm your slot and send us your slides by November 7.=20 BTW: As usual we need to organize the scribes and minute=20 takers _before_ the meeting. Please help us to start the=20 session on time and send us a note if you volunteer.=20 Thank you! Bert & Mehmet=20 ___________________________________________________=20 NETCONF WG=20 IETF 76, Stockholm, Sweden MONDAY, November 9, 2009, 1520-1720 Afternoon Session II=20 WG Chairs: Bert Wijnen Mehmet Ersue Scribes (IF no_volunteers THEN wait_forever)=20 Agenda bashing (2 minutes)=20 WG status review (5 minutes)=20 Chartered items: 1. NETCONF Monitoring Schema - Mark Scott/M. Bjorklund/S. Chisholm = (15 minutes) =20 draft-ietf-netconf-monitoring 2. 4741bis-draft - M. Bjorklund/J. Sch=F6nw=E4lder/A. Bierman (30 = minutes) draft-ietf-netconf-4741bis=20 3. With-defaults capability for NETCONF - A. Bierman/B. Lengyel = (20 minutes) draft-ietf-netconf-with-defaults Non-Chartered items: 1. RFC4742 errata and rfc4742bis - B. Wijnen/M. Ersue (15 minutes) Open mike (15 minutes) Are we ready to start Access Control work? Any other topics to discuss?=20 AOB ------_=_NextPart_001_01CA5BAB.69434EC8 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Agenda for IETF #76 NETCONF Session

Hi All,

please find below the agenda we = prepared for the
NETCONF WG session at the IETF #76. = Our session will
be on MONDAY, November 9, 2009, = 1520-1720.
 
Our main focus in the session will = be as usual on open
issue discussion. Please send us = your comments and
any additional topics you have for = discussion.

IETF secretary kindly organized a = Webex+Conference
setup for us so WG members can also = participate remotely.

Presenters please confirm your slot = and send us your slides
by November 7.

BTW: As usual we need to organize the = scribes and minute
takers _before_ the meeting. Please = help us to start the
session on time and send us a note = if you volunteer.

Thank you!

Bert & Mehmet
___________________________________________________ =


NETCONF WG
IETF 76, Stockholm, Sweden

MONDAY, November 9, 2009, 1520-1720 = Afternoon Session II

   WG Chairs:
   Bert Wijnen = <bertietf@bwijnen.net>
   Mehmet Ersue = <mehmet.ersue@nsn.com>

   Scribes (IF = no_volunteers THEN wait_forever)
   Agenda bashing (2 = minutes)
   WG status review (5 = minutes)

   Chartered items:

      1. = NETCONF Monitoring Schema - Mark Scott/M. Bjorklund/S. Chisholm (15 = minutes) 
          = draft-ietf-netconf-monitoring
      2. = 4741bis-draft - M. Bjorklund/J. Sch=F6nw=E4lder/A. Bierman (30 = minutes)
          = draft-ietf-netconf-4741bis
      3. = With-defaults capability for NETCONF - A. Bierman/B. Lengyel (20 = minutes)
          = draft-ietf-netconf-with-defaults


   Non-Chartered = items:

      1. = RFC4742 errata and rfc4742bis - B. Wijnen/M. Ersue (15 minutes)

   Open mike (15 = minutes)
      Are = we ready to start Access Control work?
      Any = other topics to discuss?

   AOB

------_=_NextPart_001_01CA5BAB.69434EC8-- From bertietf@bwijnen.net Mon Nov 2 03:05:27 2009 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B28CD3A69F1 for ; Mon, 2 Nov 2009 03:05:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.099 X-Spam-Level: X-Spam-Status: No, score=-5.099 tagged_above=-999 required=5 tests=[AWL=-2.500, BAYES_00=-2.599] 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 8ArDL5i92pfw for ; Mon, 2 Nov 2009 03:05:27 -0800 (PST) Received: from postlady.ripe.net (postlady.ripe.net [193.0.19.65]) by core3.amsl.com (Postfix) with ESMTP id D976E3A67C2 for ; Mon, 2 Nov 2009 03:05:25 -0800 (PST) Received: from herring.ripe.net ([193.0.1.203]) by postlady.ripe.net with esmtp (Exim 4.63) (envelope-from ) id 1N4uj5-0006eK-3W; Mon, 02 Nov 2009 12:05:36 +0100 Received: from guest-32.ripe.net (cat.ripe.net [193.0.1.249]) by herring.ripe.net (Postfix) with ESMTP id 12D0E2F583; Mon, 2 Nov 2009 12:05:31 +0100 (CET) Message-ID: <4AEEBCFB.3000909@bwijnen.net> Date: Mon, 02 Nov 2009 12:05:31 +0100 From: "Bert (IETF) Wijnen" User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: "Ersue, Mehmet (NSN - DE/Munich)" References: <80A0822C5E9A4440A5117C2F4CD36A640E0D40@DEMUEXC006.nsn-intra.net> In-Reply-To: <80A0822C5E9A4440A5117C2F4CD36A640E0D40@DEMUEXC006.nsn-intra.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-RIPE-Spam-Level: ---- X-RIPE-Signature: 86ab03e524994f79ca2c75a176445dd4fa5f5de1bfdc5abb2259c1fceacf0565 Cc: netconf@ietf.org Subject: Re: [Netconf] Agenda for IETF #76 NETCONF Session X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Nov 2009 11:05:27 -0000 Sorry.... w.r.t. > > Presenters please confirm your slot and send us your slides > by November 7. > Although we can deal with Nov 7th, I think we would REALLY WANT YOU TO SEND THEM EARLIER. I did post/forward yesterday: ----- Original Message ----- *From:* Adrian Farrel *Sent:* Saturday, October 31, 2009 9:25 PM *Subject:* Pre-posting of slides in Hiroshima Hi, We can expect a higher than normal number of people at our WG meetings in Hiroshima for whom English is not the first language. In discussions in Stockholm, the thing that Asian participants said would be most useful was pre-posting of the slides. This allows them to look up any difficult words, make notes, and follow along at their own speed. I know many working groups have a good record of posting slides before their meetings. Can I ask you all to make a special effort to get the material onto the IETF site ahead of your meetings (preferably at least a day ahead) as an act of courtesy and to ensure better discussions within your working groups. Thanks, Adrian From mehmet.ersue@nsn.com Mon Nov 2 05:39:36 2009 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8CB143A6976 for ; Mon, 2 Nov 2009 05:39:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001] 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 gAlTHV6C6M8v for ; Mon, 2 Nov 2009 05:39:34 -0800 (PST) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [93.183.12.31]) by core3.amsl.com (Postfix) with ESMTP id CF17A3A6960 for ; Mon, 2 Nov 2009 05:39:33 -0800 (PST) Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id nA2Ddocc010309 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Mon, 2 Nov 2009 14:39:50 +0100 Received: from demuexc022.nsn-intra.net (demuexc022.nsn-intra.net [10.150.128.35]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id nA2DdoTM023990 for ; Mon, 2 Nov 2009 14:39:50 +0100 Received: from DEMUEXC006.nsn-intra.net ([10.150.128.18]) by demuexc022.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Mon, 2 Nov 2009 14:39:50 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CA5BC1.F33052C0" Date: Mon, 2 Nov 2009 14:39:48 +0100 Message-ID: <80A0822C5E9A4440A5117C2F4CD36A640E0E27@DEMUEXC006.nsn-intra.net> In-Reply-To: <80A0822C5E9A4440A5117C2F4CD36A640E0D40@DEMUEXC006.nsn-intra.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Netconf] Agenda for IETF #76 NETCONF Session Thread-Index: Acpbq2gAheLQEOYmSHC0oWa4FnJyjQAFN+eg References: <80A0822C5E9A4440A5117C2F4CD36A640E0D40@DEMUEXC006.nsn-intra.net> From: "Ersue, Mehmet (NSN - DE/Munich)" To: X-OriginalArrivalTime: 02 Nov 2009 13:39:50.0278 (UTC) FILETIME=[F355C260:01CA5BC1] Subject: Re: [Netconf] Agenda for IETF #76 NETCONF Session X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Nov 2009 13:39:36 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CA5BC1.F33052C0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable s/Stockholm, Sweden/Hiroshima, Japan/ Mehmet=20 =20 ________________________________ From: netconf-bounces@ietf.org [mailto:netconf-bounces@ietf.org] On = Behalf Of ext Ersue, Mehmet (NSN - DE/Munich) Sent: Monday, November 02, 2009 11:58 AM To: netconf@ietf.org Subject: [Netconf] Agenda for IETF #76 NETCONF Session =09 =09 Hi All,=20 please find below the agenda we prepared for the=20 NETCONF WG session at the IETF #76. Our session will=20 be on MONDAY, November 9, 2009, 1520-1720.=20 =20 Our main focus in the session will be as usual on open=20 issue discussion. Please send us your comments and=20 any additional topics you have for discussion.=20 IETF secretary kindly organized a Webex+Conference=20 setup for us so WG members can also participate remotely.=20 Presenters please confirm your slot and send us your slides=20 by November 7.=20 BTW: As usual we need to organize the scribes and minute=20 takers _before_ the meeting. Please help us to start the=20 session on time and send us a note if you volunteer.=20 Thank you!=20 Bert & Mehmet=20 ___________________________________________________=20 NETCONF WG=20 IETF 76, Stockholm, Sweden=20 MONDAY, November 9, 2009, 1520-1720 Afternoon Session II=20 WG Chairs:=20 Bert Wijnen =20 Mehmet Ersue =20 Scribes (IF no_volunteers THEN wait_forever)=20 Agenda bashing (2 minutes)=20 WG status review (5 minutes)=20 Chartered items:=20 1. NETCONF Monitoring Schema - Mark Scott/M. Bjorklund/S. = Chisholm (15 minutes) =20 draft-ietf-netconf-monitoring=20 2. 4741bis-draft - M. Bjorklund/J. Sch=F6nw=E4lder/A. Bierman (30 = minutes)=20 draft-ietf-netconf-4741bis=20 3. With-defaults capability for NETCONF - A. Bierman/B. Lengyel = (20 minutes)=20 draft-ietf-netconf-with-defaults=20 Non-Chartered items:=20 1. RFC4742 errata and rfc4742bis - B. Wijnen/M. Ersue (15 = minutes)=20 Open mike (15 minutes)=20 Are we ready to start Access Control work?=20 Any other topics to discuss?=20 AOB=20 ------_=_NextPart_001_01CA5BC1.F33052C0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Agenda for IETF #76 NETCONF Session
s/Stockholm, Sweden/Hiroshima, = Japan/

Mehmet
 

From: netconf-bounces@ietf.org=20 [mailto:netconf-bounces@ietf.org] On Behalf Of ext Ersue, = Mehmet (NSN -=20 DE/Munich)
Sent: Monday, November 02, 2009 11:58 = AM
To:=20 netconf@ietf.org
Subject: [Netconf] Agenda for IETF #76 = NETCONF=20 Session


Hi All,

please find below the agenda we = prepared for the=20
NETCONF WG session at the = IETF #76. Our=20 session will
be on MONDAY, = November 9,=20 2009, 1520-1720.
 
Our main focus in the session will be as usual = on open=20
issue discussion. Please send = us your=20 comments and
any additional = topics you=20 have for discussion.

IETF secretary kindly organized a=20 Webex+Conference
setup for us = so WG=20 members can also participate remotely.

Presenters please confirm your slot = and send us=20 your slides
by November 7. =

BTW: As usual we need to organize the = scribes and=20 minute
takers _before_ the = meeting.=20 Please help us to start the
session on=20 time and send us a note if you volunteer.

Thank you!

Bert & Mehmet
___________________________________________________ =


NETCONF WG
IETF 76, Stockholm, Sweden

MONDAY, November 9, 2009, 1520-1720 = Afternoon=20 Session II

   WG Chairs: =
   Bert Wijnen=20 <bertietf@bwijnen.net>
  =20 Mehmet Ersue <mehmet.ersue@nsn.com>

   Scribes (IF = no_volunteers THEN=20 wait_forever)
   = Agenda bashing=20 (2 minutes)
   WG = status review=20 (5 minutes)

   Chartered items: =

      1. = NETCONF=20 Monitoring Schema - Mark Scott/M. Bjorklund/S. Chisholm (15 = minutes) =20
         =20 draft-ietf-netconf-monitoring
      2. 4741bis-draft - M. = Bjorklund/J.=20 Sch=F6nw=E4lder/A. Bierman (30 minutes)
         =20 draft-ietf-netconf-4741bis
      3. With-defaults capability = for NETCONF=20 - A. Bierman/B. Lengyel (20 minutes)
         =20 draft-ietf-netconf-with-defaults


   Non-Chartered = items:

      1. = RFC4742 errata=20 and rfc4742bis - B. Wijnen/M. Ersue (15 minutes)

   Open mike (15 = minutes)=20
      Are = we ready to=20 start Access Control work?
      Any other topics to discuss? =

   AOB=20

------_=_NextPart_001_01CA5BC1.F33052C0-- From j.schoenwaelder@jacobs-university.de Mon Nov 2 13:12:41 2009 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2C02B3A692B for ; Mon, 2 Nov 2009 13:12:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.552 X-Spam-Level: X-Spam-Status: No, score=-1.552 tagged_above=-999 required=5 tests=[AWL=0.097, BAYES_00=-2.599, HELO_EQ_DE=0.35, J_CHICKENPOX_26=0.6] 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 UYkyQpSYH0FS for ; Mon, 2 Nov 2009 13:12:39 -0800 (PST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 846E928C0F4 for ; Mon, 2 Nov 2009 13:12:15 -0800 (PST) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 3E940C0024 for ; Mon, 2 Nov 2009 22:12:35 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius3.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id jPgyfNBSHfuX; Mon, 2 Nov 2009 22:12:33 +0100 (CET) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 1A0C3C0021; Mon, 2 Nov 2009 22:12:33 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id AC84AD9E9F9; Mon, 2 Nov 2009 22:12:32 +0100 (CET) Date: Mon, 2 Nov 2009 22:12:32 +0100 From: Juergen Schoenwaelder To: netconf@ietf.org Message-ID: <20091102211232.GA4455@elstar.local> Mail-Followup-To: netconf@ietf.org References: <085091CB2CA14E4B8B163FFC37C84E9D1A9F69CD@zcarhxm0.corp.nortel.com> <80A0822C5E9A4440A5117C2F4CD36A64031460@DEMUEXC006.nsn-intra.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <80A0822C5E9A4440A5117C2F4CD36A64031460@DEMUEXC006.nsn-intra.net> User-Agent: Mutt/1.5.20 (2009-06-14) Subject: [Netconf] draft-ietf-netconf-monitoring-09 last call comments from js X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Nov 2009 21:12:41 -0000 On Tue, Oct 20, 2009 at 02:36:24PM +0200, Ersue, Mehmet (NSN - DE/Munich) wrote: > With this mail we start a new WGLC for the NETCONF > monitoring draft, which is planned to publish as a > Proposed Standard RFC. The WGLC will run until > November 2, 2009. I have reviewed the monitoring document and below are my comments. I quoted (using the : marker) text from the monitoring document and then wrote down my comments/questions/suggestions. I did not find any show stoppers, but I believe more editing work (means at least one more revision) is to be done to get this document into good shape. : [...] The : capabilities of a NETCONF server may change over time. However, once : a NETCONF server has announced its capabilities in the : message, the capabilities for that session MUST NOT change. A server : MUST reply with a 'capabilities-changed' error if the client sends a : request which is affected by a modified capability. A server MAY : choose to send 'capabilities-changed' as the response to any request : other than if its capabilities has changed. It seems to me that it is not the job of the monitoring document to establish rules how NETCONF works. I suggest to remove this text and to include such text in RFC 4741bis instead. : Through updated monitoring data NETCONF clients can adjust their : capabilities throughout a session. I wonder how this is supposed to work. Once the server starts to generate 'capabilities-changed' errors, I need an explicit resync action - reading the monitoring data can hardly be sufficient to declare that things are not synchronized again. : Schema: A machine readable data model definition. The schema is : independent of which data modeling language is used for the data : model. I have trouble to understand the second sentence. Every machine readable data model is written in a specific format. So how can the schema be format specific and at the same time independent? Perhaps the second sentence should just be removed. : The following data allows a NETCONF client to monitor both the : NETCONF server itself and the associated network device operational : data. I wonder what "associated network device operational data" means. I thought the YANG model only reports NETCONF server operational state and statistics. : To provide clients the ability to manage locked resources lock : information is provided for each ConfigurationDataStore instance. I have no clue what this ConfigurationDataStore instance is. : For YANG data models, the format is one of "yang" or "yin". I am concerned about interoperability here. I prefer that the "yang" format is required and "yin" can be provided optionally. Otherwise, you require that all management applications have two parsers instead of one. : A schema entry may be located on a network device (eg: xs:anyURI), : a remote file system (eg: xs:string reference to file system for : ftp retrieval) or available explicitly via NETCONF (xs:string : value 'NETCONF') for NETCONF servers which support the : operation. You probably want to replace the references to XSD types for consistency. : For YANG data models, this is the module's namespace. If the list : entry describes a submodule, this field contains the namespace of : the module to which the submodule belongs. This text seems misplaced since I believe this has nothing to do with the location. : Includes session specific data for NETCONF management sessions. : The session list MUST include all currently active NETCONF sessions, : and MAY include other sessions as well. It is unclear what "other sessions" mean. If you mean "inactive" sessions or "recently closed sessions", simply say so. If you mean non NETCONF sessions, well that that kind of violates the first sentence. Please clarify. : For purposes of NETCONF management all sessions are one of: : : Known session: any session which can be managed by the : NETCONF server SHOULD be reported in this table. : : Unknown session: such sessions are not managed by the : NETCONF server and map to NETCONF session identifier 0. : These MUST be excluded from the session table as a result. I dislike the word table - XML is not tables like SMIv2. That said, I find the text confusing. What you are really saying is: Monitoring data is only provided for session with a non-zero session-id. : transport (identityref, transport) : Idenfities type for each session, e.g. "netconf-ssh", : "netconf-soap", etc. Replace with "Identifies that transport for each ..." : username (string) : If present, the username contains an identifier which can be : used to uniquely identify an individual client (human or : machine). This is likely to be implementation specific and : subject to the security requirements of the device vendor : and/or operators, e.g., an SSH user, a host RSA fingerprint : or other identifier deemed acceptable. I do not want to boil the ocean, but we will likely have to work this out in more detail later when access control is defined and we need a deterministic way to derive a username from whatever has been used for authentication. Those who follow the ISMS work will know why I have to comment on this. So take this as a warning that in the future, we will have to define much more precise ways to derive a username if we associate access control rules with user identities. : When the schema is available on the device this operation is : used to return it via NETCONF. This conditional sentence sounds backwards. What about this: This operation can be used to retrieve a schema form the NETCONF server. : module bar { : bar version 2008-06-01 yang module : contents here ... : } Make this legal yang by using comments: module bar { // bar version 2008-06-01 yang module // contents here ... } : module bar-types { : bar-types version 2008-06-01 yang module : contents here ... : } Make this legal yang by using comments: module bar-types { // bar-types version 2008-06-01 yang module // contents here ... } : identity transport { : description : "Base identity for session types."; : } This should be "Base identity for NETCONF transports.". Please remove all mentions of "session types". : reference "RFC 4742"; Replace with reference "RFC 4742: Using the NETCONF Configuration Protocol over Secure SHell (SSH)"; : reference "RFC 4743"; Replace with reference "RFC 4743: Using NETCONF over the Simple Object Access Protocol (SOAP)"; : reference "RFC 4744"; Replace with reference "RFC 4744: Using the NETCONF Protocol over the Blocks Extensible Exchange Protocol (BEEP)"; : reference "RFC 5539"; Replace with reference "RFC 5539: NETCONF over Transport Layer Security (TLS)"; : reference "W3C REC REC-xmlschema-1-20041028"; Replace with reference "W3C REC REC-xmlschema-1-20041028: XML Schema Part 1: Structure W3C REC REC-xmlschema-2-20041028: XML Schema Part 2: Datatypes"; : reference "ISO/IEC 19757-2"; Replace with reference "ISO/IEC 19757-2: RELAX NG"; : reference "ISO/IEC 19757-2"; Replace with reference "ISO/IEC 19757-2: RELAX NG"; : list partial-locks { : key lock-id; : description : "For a partial lock this is the lock id returned : in the response."; : leaf lock-id { : type uint32; : } The description like should be a description of the leaf lock-id and not the partial-locks list itself. : list session { : key session-id; : leaf session-id { : type session-id; : } : leaf transport { : mandatory true; : type identityref { : base transport; : } : } : leaf username { : type string; : } : leaf source-host { : type inet:host; : } I am badly missing description statements here. In general, it seems that many description statements leave out details that are explained in section 2. In SMIv2 land, it was considered good practice to have all normative texts in the data model so that the text is there once extracted from the RFC. I believe we should follow this practice and move most of the text from section 2.1 into description clauses. This also avoids any potential inconsistencies. leaf login-time { mandatory true; type yang:date-and-time; description "Time at which the session was established."; } I am wondering why some objects are mandatory while others are not. For example, why is the login-time mandatory while the netconf-start-time is not mandatory? It is not clear to me as a reader whether there are any specific requirements on login-time that give it a special status and that do not apply to netconf-start-time. Finally, I like to comment that I find the choice lock-type a somewhat artifical construction. I understand that a global lock and a partial lock can't exist together. Still, I would have modeled a simple global-lock container and a partial-locks list. I find this somewhat simpler to follow, also because partial locks really are a feature. (The model does not really distinguish features in general.) But perhaps this is just a style issue and not really important to agree on. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From phil@juniper.net Mon Nov 2 18:53:25 2009 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5C86B3A6862 for ; Mon, 2 Nov 2009 18:53:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.547 X-Spam-Level: X-Spam-Status: No, score=-6.547 tagged_above=-999 required=5 tests=[AWL=0.052, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 cRK851VpEbpx for ; Mon, 2 Nov 2009 18:53:24 -0800 (PST) Received: from exprod7og101.obsmtp.com (exprod7og101.obsmtp.com [64.18.2.155]) by core3.amsl.com (Postfix) with ESMTP id 55E423A680A for ; Mon, 2 Nov 2009 18:53:24 -0800 (PST) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob101.postini.com ([64.18.6.12]) with SMTP ID DSNKSu+bNgeh3jgZ8aMLu7Pz4wfXzYYzQI4f@postini.com; Mon, 02 Nov 2009 18:53:45 PST Received: from p-emfe01-sac.jnpr.net (66.129.254.72) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server id 8.1.375.2; Mon, 2 Nov 2009 18:51:48 -0800 Received: from p-emlb02-sac.jnpr.net ([66.129.254.47]) by p-emfe01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Mon, 2 Nov 2009 18:51:48 -0800 Received: from emailsmtp56.jnpr.net ([172.24.60.77]) by p-emlb02-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Mon, 2 Nov 2009 18:51:47 -0800 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp56.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Mon, 2 Nov 2009 18:51:47 -0800 Received: from idle.juniper.net (idleski.juniper.net [172.25.4.26]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id nA32plj60490; Mon, 2 Nov 2009 18:51:47 -0800 (PST) (envelope-from phil@juniper.net) Received: from idle.juniper.net (localhost [127.0.0.1]) by idle.juniper.net (8.13.8/8.13.8) with ESMTP id nA32cchn053137; Tue, 3 Nov 2009 02:38:39 GMT (envelope-from phil@idle.juniper.net) Message-ID: <200911030238.nA32cchn053137@idle.juniper.net> To: Juergen Schoenwaelder In-Reply-To: <20091102211232.GA4455@elstar.local> Date: Mon, 2 Nov 2009 21:38:38 -0500 From: Phil Shafer X-OriginalArrivalTime: 03 Nov 2009 02:51:47.0513 (UTC) FILETIME=[95D06A90:01CA5C30] MIME-Version: 1.0 Content-Type: text/plain Cc: netconf@ietf.org Subject: Re: [Netconf] draft-ietf-netconf-monitoring-09 last call comments from js X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Nov 2009 02:53:25 -0000 Juergen Schoenwaelder writes: >: username (string) >: If present, the username contains an identifier which can be >: used to uniquely identify an individual client (human or >: machine). This is likely to be implementation specific and >: subject to the security requirements of the device vendor >: and/or operators, e.g., an SSH user, a host RSA fingerprint >: or other identifier deemed acceptable. > >I do not want to boil the ocean, but we will likely have to work this >out in more detail later when access control is defined and we need a >deterministic way to derive a username from whatever has been used for >authentication. Those who follow the ISMS work will know why I have to >comment on this. So take this as a warning that in the future, we will >have to define much more precise ways to derive a username if we >associate access control rules with user identities. There's also the issue of radius/tacplus users, where the "user name" and "login name" are distinct and both are needed. >: When the schema is available on the device this operation is >: used to return it via NETCONF. > >This conditional sentence sounds backwards. What about this: > > This operation can be used to retrieve a schema form the NETCONF > server. Needs to indicate that the schema form cannot always be retrived. My earlier suggestion was s/When/If/, but that wasn't incorporated. >I am badly missing description statements here. In general, it seems >that many description statements leave out details that are explained >in section 2. In SMIv2 land, it was considered good practice to have >all normative texts in the data model so that the text is there once >extracted from the RFC. I believe we should follow this practice and >move most of the text from section 2.1 into description clauses. This >also avoids any potential inconsistencies. Amen. Can we go further and encourage the YANG module to _be_ the full RFC, so extracting the module gives the full normative text of the RFC inside the module? So the RFC is some introductory text, followed by the YANG module with all the normative text as comments or descriptions inside that file. Extracting the module gives you everything and there's not duplicate text to get out of sync or to add confusion. Thanks, Phil From j.schoenwaelder@jacobs-university.de Mon Nov 2 23:11:39 2009 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AEC723A68B0 for ; Mon, 2 Nov 2009 23:11:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.854 X-Spam-Level: X-Spam-Status: No, score=-1.854 tagged_above=-999 required=5 tests=[AWL=0.395, BAYES_00=-2.599, HELO_EQ_DE=0.35] 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 N8Fx8jggR0F9 for ; Mon, 2 Nov 2009 23:11:38 -0800 (PST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 5F59928C152 for ; Mon, 2 Nov 2009 23:11:37 -0800 (PST) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 98F59C0005; Tue, 3 Nov 2009 08:11:57 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius3.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id PE7TW7EnVf0t; Tue, 3 Nov 2009 08:11:56 +0100 (CET) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 475FDC0003; Tue, 3 Nov 2009 08:11:55 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 8430FD9F04B; Tue, 3 Nov 2009 08:11:55 +0100 (CET) Date: Tue, 3 Nov 2009 08:11:55 +0100 From: Juergen Schoenwaelder To: Phil Shafer Message-ID: <20091103071155.GA5038@elstar.local> Mail-Followup-To: Phil Shafer , "netconf@ietf.org" References: <20091102211232.GA4455@elstar.local> <200911030238.nA32cchn053137@idle.juniper.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200911030238.nA32cchn053137@idle.juniper.net> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: "netconf@ietf.org" Subject: Re: [Netconf] draft-ietf-netconf-monitoring-09 last call comments from js X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Nov 2009 07:11:39 -0000 On Tue, Nov 03, 2009 at 03:38:38AM +0100, Phil Shafer wrote: > Juergen Schoenwaelder writes: > >: username (string) > >: If present, the username contains an identifier which can be > >: used to uniquely identify an individual client (human or > >: machine). This is likely to be implementation specific and > >: subject to the security requirements of the device vendor > >: and/or operators, e.g., an SSH user, a host RSA fingerprint > >: or other identifier deemed acceptable. > > > >I do not want to boil the ocean, but we will likely have to work this > >out in more detail later when access control is defined and we need a > >deterministic way to derive a username from whatever has been used for > >authentication. Those who follow the ISMS work will know why I have to > >comment on this. So take this as a warning that in the future, we will > >have to define much more precise ways to derive a username if we > >associate access control rules with user identities. > > There's also the issue of radius/tacplus users, where the "user > name" and "login name" are distinct and both are needed. Not sure I understand your comment - why does radius/tacplus lead to a difference between a "user name" and a "login name"? Which AVPs are you referring to? > >I am badly missing description statements here. In general, it seems > >that many description statements leave out details that are explained > >in section 2. In SMIv2 land, it was considered good practice to have > >all normative texts in the data model so that the text is there once > >extracted from the RFC. I believe we should follow this practice and > >move most of the text from section 2.1 into description clauses. This > >also avoids any potential inconsistencies. > > Amen. Can we go further and encourage the YANG module to _be_ > the full RFC, so extracting the module gives the full normative > text of the RFC inside the module? So the RFC is some introductory > text, followed by the YANG module with all the normative text as > comments or descriptions inside that file. Extracting the module > gives you everything and there's not duplicate text to get out of > sync or to add confusion. This is pretty much what we have been doing in SMIv2 land. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From dromasca@avaya.com Tue Nov 3 02:33:58 2009 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 16A7D3A635F for ; Tue, 3 Nov 2009 02:33:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.465 X-Spam-Level: X-Spam-Status: No, score=-2.465 tagged_above=-999 required=5 tests=[AWL=0.134, BAYES_00=-2.599] 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 Y9-tPA-8dhVo for ; Tue, 3 Nov 2009 02:33:57 -0800 (PST) Received: from nj300815-nj-outbound.net.avaya.com (nj300815-nj-outbound.net.avaya.com [198.152.12.100]) by core3.amsl.com (Postfix) with ESMTP id 242003A6966 for ; Tue, 3 Nov 2009 02:33:57 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.44,673,1249272000"; d="scan'208";a="179013677" Received: from unknown (HELO nj300815-nj-erheast.avaya.com) ([198.152.6.5]) by nj300815-nj-outbound.net.avaya.com with ESMTP; 03 Nov 2009 05:34:16 -0500 Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.12]) by nj300815-nj-erheast-out.avaya.com with ESMTP; 03 Nov 2009 05:34:15 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 3 Nov 2009 11:34:14 +0100 Message-ID: In-Reply-To: <20091103071155.GA5038@elstar.local> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Netconf] draft-ietf-netconf-monitoring-09 last call comments from js Thread-Index: AcpcVPJ0AiTMtsbsTn+E7645By7jQAAG5bQg References: <20091102211232.GA4455@elstar.local><200911030238.nA32cchn053137@idle.juniper.net> <20091103071155.GA5038@elstar.local> From: "Romascanu, Dan (Dan)" To: "Juergen Schoenwaelder" , "Phil Shafer" Cc: netconf@ietf.org Subject: Re: [Netconf] draft-ietf-netconf-monitoring-09 last call comments from js X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Nov 2009 10:33:58 -0000 =20 > -----Original Message----- > >=20 > > Amen. Can we go further and encourage the YANG module to _be_ the=20 > > full RFC, so extracting the module gives the full normative text of=20 > > the RFC inside the module? So the RFC is some introductory text,=20 > > followed by the YANG module with all the normative text as=20 > comments or=20 > > descriptions inside that file. Extracting the module gives you=20 > > everything and there's not duplicate text to get out of=20 > sync or to add=20 > > confusion. >=20 > This is pretty much what we have been doing in SMIv2 land. >=20 > /js >=20 Yes. This may be straighten up in the guideline document - http://www.ietf.org/id/draft-ietf-netmod-yang-usage-02.txt .=20 While completing avoiding duplication is not always possible it should be made clear that the YANG module is the normative text. Useful information may be present in the RFC (like security considerations, relations with other modules, application examples, etc.) but the information in the module itself should be complete enough to allow for implementation. Dan From phil@juniper.net Tue Nov 3 06:10:52 2009 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1CECE28C0E2 for ; Tue, 3 Nov 2009 06:10:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.548 X-Spam-Level: X-Spam-Status: No, score=-6.548 tagged_above=-999 required=5 tests=[AWL=0.051, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 dndl02W8YSkL for ; Tue, 3 Nov 2009 06:10:51 -0800 (PST) Received: from exprod7og104.obsmtp.com (exprod7og104.obsmtp.com [64.18.2.161]) by core3.amsl.com (Postfix) with ESMTP id 9C7F328C196 for ; Tue, 3 Nov 2009 06:10:46 -0800 (PST) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob104.postini.com ([64.18.6.12]) with SMTP ID DSNKSvA5+Hj9SzOXVq5vhLiWBTRol8nYnVCW@postini.com; Tue, 03 Nov 2009 06:11:07 PST Received: from p-emfe01-sac.jnpr.net (66.129.254.72) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server id 8.1.375.2; Tue, 3 Nov 2009 06:04:20 -0800 Received: from p-emlb02-sac.jnpr.net ([66.129.254.47]) by p-emfe01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 3 Nov 2009 06:04:20 -0800 Received: from emailsmtp56.jnpr.net ([172.24.60.77]) by p-emlb02-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 3 Nov 2009 06:04:20 -0800 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp56.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 3 Nov 2009 06:04:19 -0800 Received: from idle.juniper.net (idleski.juniper.net [172.25.4.26]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id nA3E4Ij53066; Tue, 3 Nov 2009 06:04:19 -0800 (PST) (envelope-from phil@juniper.net) Received: from idle.juniper.net (localhost [127.0.0.1]) by idle.juniper.net (8.13.8/8.13.8) with ESMTP id nA3DpATf064781; Tue, 3 Nov 2009 13:51:10 GMT (envelope-from phil@idle.juniper.net) Message-ID: <200911031351.nA3DpATf064781@idle.juniper.net> To: Juergen Schoenwaelder In-Reply-To: <20091103071155.GA5038@elstar.local> Date: Tue, 3 Nov 2009 08:51:09 -0500 From: Phil Shafer X-OriginalArrivalTime: 03 Nov 2009 14:04:19.0537 (UTC) FILETIME=[897EA410:01CA5C8E] MIME-Version: 1.0 Content-Type: text/plain Cc: "netconf@ietf.org" Subject: Re: [Netconf] draft-ietf-netconf-monitoring-09 last call comments from js X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Nov 2009 14:10:52 -0000 Juergen Schoenwaelder writes: >Not sure I understand your comment - why does radius/tacplus lead to a >difference between a "user name" and a "login name"? Which AVPs are >you referring to? AVP? My comment has that with radius I can login as one user and have the radius server return a different user name to use locally, so I can remotely administer a hundred operators as a single "operator" local user. So the permissions may track with the real user name ("operator") but the login name ("phil") is also vital information. >This is pretty much what we have been doing in SMIv2 land. Cool. I've seen examples that aren't this way, where the MIB text documents the leafs, but not their meaning. An example would be rfc3412, where in a ~40 page rfc, the mib is ~3 pages. Thanks, Phil From j.schoenwaelder@jacobs-university.de Tue Nov 3 06:22:21 2009 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B923328C0EC for ; Tue, 3 Nov 2009 06:22:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.865 X-Spam-Level: X-Spam-Status: No, score=-1.865 tagged_above=-999 required=5 tests=[AWL=0.384, BAYES_00=-2.599, HELO_EQ_DE=0.35] 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 LrtBG7nu+tmP for ; Tue, 3 Nov 2009 06:22:21 -0800 (PST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id A40183A698D for ; Tue, 3 Nov 2009 06:22:20 -0800 (PST) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id D2FD2C0027; Tue, 3 Nov 2009 15:22:40 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius3.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id dy9tueFlkMqO; Tue, 3 Nov 2009 15:22:39 +0100 (CET) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id D805AC0005; Tue, 3 Nov 2009 15:22:39 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 73763DA01CF; Tue, 3 Nov 2009 15:22:39 +0100 (CET) Date: Tue, 3 Nov 2009 15:22:39 +0100 From: Juergen Schoenwaelder To: Phil Shafer Message-ID: <20091103142239.GA7302@elstar.local> Mail-Followup-To: Phil Shafer , "netconf@ietf.org" References: <20091103071155.GA5038@elstar.local> <200911031351.nA3DpATf064781@idle.juniper.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200911031351.nA3DpATf064781@idle.juniper.net> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: "netconf@ietf.org" Subject: Re: [Netconf] draft-ietf-netconf-monitoring-09 last call comments from js X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Nov 2009 14:22:21 -0000 On Tue, Nov 03, 2009 at 02:51:09PM +0100, Phil Shafer wrote: > Juergen Schoenwaelder writes: > >Not sure I understand your comment - why does radius/tacplus lead to a > >difference between a "user name" and a "login name"? Which AVPs are > >you referring to? > > AVP? My comment has that with radius I can login as one user and > have the radius server return a different user name to use locally, > so I can remotely administer a hundred operators as a single > "operator" local user. So the permissions may track with the real > user name ("operator") but the login name ("phil") is also vital > information. Tell me how this works (AVPs are the things RADIUS sends around in the payload) - or better tell me not, since this would impact ISMS badly. > >This is pretty much what we have been doing in SMIv2 land. > > Cool. I've seen examples that aren't this way, where the > MIB text documents the leafs, but not their meaning. An > example would be rfc3412, where in a ~40 page rfc, the mib > is ~3 pages. You won't expect TCP objects to document how TCP works, right. The same logic applies to RFC 3412 and all the other SNMP RFCs. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From phil@juniper.net Tue Nov 3 06:59:53 2009 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 848EC3A6A07 for ; Tue, 3 Nov 2009 06:59:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[AWL=-0.250, BAYES_00=-2.599, J_CHICKENPOX_34=0.6, RCVD_IN_DNSWL_MED=-4] 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 wXfAsMb+gKGA for ; Tue, 3 Nov 2009 06:59:52 -0800 (PST) Received: from exprod7og116.obsmtp.com (exprod7og116.obsmtp.com [64.18.2.219]) by core3.amsl.com (Postfix) with ESMTP id 88EBA3A69AC for ; Tue, 3 Nov 2009 06:59:52 -0800 (PST) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob116.postini.com ([64.18.6.12]) with SMTP ID DSNKSvBFel8wYcMUcvdwoMkQcYNHUbxpI+4J@postini.com; Tue, 03 Nov 2009 07:00:13 PST Received: from p-emfe01-sac.jnpr.net (66.129.254.72) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server id 8.1.375.2; Tue, 3 Nov 2009 06:46:08 -0800 Received: from p-emlb01-sac.jnpr.net ([66.129.254.46]) by p-emfe01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 3 Nov 2009 06:46:09 -0800 Received: from emailsmtp56.jnpr.net ([172.24.60.77]) by p-emlb01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 3 Nov 2009 06:46:08 -0800 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp56.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 3 Nov 2009 06:46:07 -0800 Received: from idle.juniper.net (idleski.juniper.net [172.25.4.26]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id nA3Ek7j79683; Tue, 3 Nov 2009 06:46:07 -0800 (PST) (envelope-from phil@juniper.net) Received: from idle.juniper.net (localhost [127.0.0.1]) by idle.juniper.net (8.13.8/8.13.8) with ESMTP id nA3EWxSg065216; Tue, 3 Nov 2009 14:32:59 GMT (envelope-from phil@idle.juniper.net) Message-ID: <200911031432.nA3EWxSg065216@idle.juniper.net> To: Juergen Schoenwaelder In-Reply-To: <20091103142239.GA7302@elstar.local> Date: Tue, 3 Nov 2009 09:32:58 -0500 From: Phil Shafer X-OriginalArrivalTime: 03 Nov 2009 14:46:07.0863 (UTC) FILETIME=[6092D070:01CA5C94] MIME-Version: 1.0 Content-Type: text/plain Cc: "netconf@ietf.org" Subject: Re: [Netconf] draft-ietf-netconf-monitoring-09 last call comments from js X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Nov 2009 14:59:53 -0000 Juergen Schoenwaelder writes: >Tell me how this works (AVPs are the things RADIUS sends around in the >payload) - or better tell me not, since this would impact ISMS badly. Look for "JUNOS Configuration" in: http://www.cymru.com/gillsr/documents/junos-radius-authentication.htm >You won't expect TCP objects to document how TCP works, right. The >same logic applies to RFC 3412 and all the other SNMP RFCs. No, but I would expect the tcp.yang to fully describe how the tcp objects work, not just that this leaf has a range of such and the leaf is a boolean. Given that we can say: description " Lots of very detailed text. More detailed text. "; and: /* Some detailed text that needn't be in the description statement. */ And given the number of mib implementors that seem to not read the rfc, just the mib, I'd vote to have all real text live within the yang module. Thanks, Phil From mbj@tail-f.com Tue Nov 3 07:03:41 2009 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A24E23A6A21 for ; Tue, 3 Nov 2009 07:03:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.97 X-Spam-Level: X-Spam-Status: No, score=-1.97 tagged_above=-999 required=5 tests=[AWL=0.076, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] 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 8ClyMpSrDVke for ; Tue, 3 Nov 2009 07:03:41 -0800 (PST) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id DE9E73A69CB for ; Tue, 3 Nov 2009 07:03:40 -0800 (PST) Received: from localhost (c213-100-167-236.swipnet.se [213.100.167.236]) by mail.tail-f.com (Postfix) with ESMTPSA id 9295076C5B7; Tue, 3 Nov 2009 16:04:00 +0100 (CET) Date: Tue, 03 Nov 2009 16:04:00 +0100 (CET) Message-Id: <20091103.160400.23684688.mbj@tail-f.com> To: phil@juniper.net From: Martin Bjorklund In-Reply-To: <200911031432.nA3EWxSg065216@idle.juniper.net> References: <20091103142239.GA7302@elstar.local> <200911031432.nA3EWxSg065216@idle.juniper.net> X-Mailer: Mew version 6.2.51 on Emacs 22.2 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: netconf@ietf.org Subject: Re: [Netconf] draft-ietf-netconf-monitoring-09 last call comments from js X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Nov 2009 15:03:41 -0000 Phil Shafer wrote: > And given the number of mib implementors that seem to not read the > rfc, just the mib, I'd vote to have all real text live within the > yang module. I also agree. For this particular document, it started out with an XSD model, and having all the text in the XSD was not very readable. But now that we moved to YANG, I agree that descriptive text should be moved into the description clauses. /martin From j.schoenwaelder@jacobs-university.de Tue Nov 3 07:22:14 2009 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E64F63A6832 for ; Tue, 3 Nov 2009 07:22:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.575 X-Spam-Level: X-Spam-Status: No, score=-1.575 tagged_above=-999 required=5 tests=[AWL=0.074, BAYES_00=-2.599, HELO_EQ_DE=0.35, J_CHICKENPOX_34=0.6] 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 ioV1RKyQMdYx for ; Tue, 3 Nov 2009 07:22:14 -0800 (PST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id DCA673A67B0 for ; Tue, 3 Nov 2009 07:22:13 -0800 (PST) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 73FA7C0029; Tue, 3 Nov 2009 16:22:34 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius2.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id YUcjjDiFgyCt; Tue, 3 Nov 2009 16:22:33 +0100 (CET) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 63FF0C0025; Tue, 3 Nov 2009 16:22:33 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 21A80DA0674; Tue, 3 Nov 2009 16:22:33 +0100 (CET) Date: Tue, 3 Nov 2009 16:22:33 +0100 From: Juergen Schoenwaelder To: Phil Shafer Message-ID: <20091103152233.GA7621@elstar.local> Mail-Followup-To: Phil Shafer , "netconf@ietf.org" References: <20091103142239.GA7302@elstar.local> <200911031432.nA3EWxSg065216@idle.juniper.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200911031432.nA3EWxSg065216@idle.juniper.net> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: "netconf@ietf.org" Subject: Re: [Netconf] draft-ietf-netconf-monitoring-09 last call comments from js X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Nov 2009 15:22:15 -0000 On Tue, Nov 03, 2009 at 03:32:58PM +0100, Phil Shafer wrote: > Juergen Schoenwaelder writes: > >Tell me how this works (AVPs are the things RADIUS sends around in the > >payload) - or better tell me not, since this would impact ISMS badly. > > Look for "JUNOS Configuration" in: > > http://www.cymru.com/gillsr/documents/junos-radius-authentication.htm That seems to be a Juniper specific thing and given my experience with IETF Radius folks, they might or might not agree this is good usage of Radius. RFC 5607 seems the closest in the IETF world as it provides a Management-Policy-Id - this Management-Policy-Id might be used for access control decisions. But it is not changing the user identity. Anyway, this gets us deeply into terminology issues and implementation details - we will have to go there if we do access control work. Lets not do it now. > >You won't expect TCP objects to document how TCP works, right. The > >same logic applies to RFC 3412 and all the other SNMP RFCs. > > No, but I would expect the tcp.yang to fully describe how the tcp > objects work, not just that this leaf has a range of such and the > leaf is a boolean. Given that we can say: > > description " > > Lots of very detailed text. > More detailed text. > > "; > > and: > > /* > > Some detailed text that needn't be in the description statement. > > */ > > And given the number of mib implementors that seem to not read the > rfc, just the mib, I'd vote to have all real text live within the > yang module. We both agree on the principle - I just disagree with your citation of RFC 3412 in an attempt to prove me wrong that the SMIv2 practice has been for a long time to have MIB modules self-contained. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From phil@juniper.net Tue Nov 3 09:04:25 2009 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 368023A691D for ; Tue, 3 Nov 2009 09:04:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.544 X-Spam-Level: X-Spam-Status: No, score=-6.544 tagged_above=-999 required=5 tests=[AWL=0.055, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 UelZOS3Ub-uq for ; Tue, 3 Nov 2009 09:04:24 -0800 (PST) Received: from exprod7og122.obsmtp.com (exprod7og122.obsmtp.com [64.18.2.22]) by core3.amsl.com (Postfix) with ESMTP id 45C0B3A683D for ; Tue, 3 Nov 2009 09:04:24 -0800 (PST) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob122.postini.com ([64.18.6.12]) with SMTP ID DSNKSvBiq94IvMPMCudBbsouhWhGziGpxRXE@postini.com; Tue, 03 Nov 2009 09:04:45 PST Received: from p-emfe01-sac.jnpr.net (66.129.254.72) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server id 8.1.375.2; Tue, 3 Nov 2009 08:57:57 -0800 Received: from p-emlb01-sac.jnpr.net ([66.129.254.46]) by p-emfe01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 3 Nov 2009 08:57:57 -0800 Received: from emailsmtp56.jnpr.net ([172.24.60.77]) by p-emlb01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 3 Nov 2009 08:57:57 -0800 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp56.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 3 Nov 2009 08:57:56 -0800 Received: from idle.juniper.net (idleski.juniper.net [172.25.4.26]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id nA3Gvtj65003; Tue, 3 Nov 2009 08:57:55 -0800 (PST) (envelope-from phil@juniper.net) Received: from idle.juniper.net (localhost [127.0.0.1]) by idle.juniper.net (8.13.8/8.13.8) with ESMTP id nA3Giltp066325; Tue, 3 Nov 2009 16:44:47 GMT (envelope-from phil@idle.juniper.net) Message-ID: <200911031644.nA3Giltp066325@idle.juniper.net> To: Juergen Schoenwaelder In-Reply-To: <20091103152233.GA7621@elstar.local> Date: Tue, 3 Nov 2009 11:44:47 -0500 From: Phil Shafer X-OriginalArrivalTime: 03 Nov 2009 16:57:56.0141 (UTC) FILETIME=[CA4645D0:01CA5CA6] MIME-Version: 1.0 Content-Type: text/plain Cc: "netconf@ietf.org" Subject: Re: [Netconf] draft-ietf-netconf-monitoring-09 last call comments from js X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Nov 2009 17:04:25 -0000 Juergen Schoenwaelder writes: >That seems to be a Juniper specific thing and given my experience with >IETF Radius folks, they might or might not agree this is good usage of >Radius. IOS does this also, and this behavior exists for both radius and tacplus. I'd be surprised if other vendors do not do this, since customers don't tend to be flexible on password administration issues, at least for larger ISPs. Thanks, Phil From randy_presuhn@mindspring.com Tue Nov 3 09:42:20 2009 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C202B3A6A4D for ; Tue, 3 Nov 2009 09:42:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.079 X-Spam-Level: X-Spam-Status: No, score=-2.079 tagged_above=-999 required=5 tests=[AWL=0.520, BAYES_00=-2.599] 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 xgEBS5MMTLLP for ; Tue, 3 Nov 2009 09:42:18 -0800 (PST) Received: from elasmtp-masked.atl.sa.earthlink.net (elasmtp-masked.atl.sa.earthlink.net [209.86.89.68]) by core3.amsl.com (Postfix) with ESMTP id AB52B3A6783 for ; Tue, 3 Nov 2009 09:42:18 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=kgGht0wDEgMEatCbr8EtakWbSDAZF2SAi6HWl6GdpqVxXib6WQRRYWhvzT3k0ucW; h=Received:Message-ID:From:To:References:Subject:Date:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Priority:X-MSMail-Priority:X-Mailer:X-MimeOLE:X-ELNK-Trace:X-Originating-IP; Received: from [99.23.160.25] (helo=oemcomputer) by elasmtp-masked.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1N5NOv-0000th-Au for netconf@ietf.org; Tue, 03 Nov 2009 12:42:37 -0500 Message-ID: <001b01ca5ca4$ad010e80$6801a8c0@oemcomputer> From: "Randy Presuhn" To: References: <20091103142239.GA7302@elstar.local><200911031432.nA3EWxSg065216@idle.juniper.net> <20091103152233.GA7621@elstar.local> Date: Tue, 3 Nov 2009 09:42:46 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-ELNK-Trace: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d8881afdcb5313ff34f9f445afcd06250bd668bd1f7840bd9225350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 99.23.160.25 Subject: Re: [Netconf] draft-ietf-netconf-monitoring-09 last call comments from js X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Nov 2009 17:42:20 -0000 Hi - > From: "Juergen Schoenwaelder" > To: "Phil Shafer" > Cc: > Sent: Tuesday, November 03, 2009 8:22 AM > Subject: Re: [Netconf] draft-ietf-netconf-monitoring-09 last call comments from js ... > > And given the number of mib implementors that seem to not read the > > rfc, just the mib, I'd vote to have all real text live within the > > yang module. > > We both agree on the principle - I just disagree with your citation of > RFC 3412 in an attempt to prove me wrong that the SMIv2 practice has > been for a long time to have MIB modules self-contained. I agree with Juergen. Yes, the stuff relevant to management should be in the MIB module. However, most RFCs with MIBs describe a system or protocol that actually *does* something other than just sit around and be managed, and many of these operational characteristics are not (and should not) be subject to management control or monitoring. Such information does not belong in a MIB module. Randy From andy@netconfcentral.com Thu Nov 5 09:52:18 2009 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 620CA28C0F2 for ; Thu, 5 Nov 2009 09:52:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.181 X-Spam-Level: X-Spam-Status: No, score=-1.181 tagged_above=-999 required=5 tests=[AWL=-0.442, BAYES_20=-0.74, UNPARSEABLE_RELAY=0.001] 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 gQkNELaCuvvx for ; Thu, 5 Nov 2009 09:52:17 -0800 (PST) Received: from n15.bullet.mail.mud.yahoo.com (n15.bullet.mail.mud.yahoo.com [68.142.206.42]) by core3.amsl.com (Postfix) with SMTP id 7AD0428C0D8 for ; Thu, 5 Nov 2009 09:52:17 -0800 (PST) Received: from [68.142.200.224] by n15.bullet.mail.mud.yahoo.com with NNFMP; 05 Nov 2009 17:52:38 -0000 Received: from [68.142.201.250] by t5.bullet.mud.yahoo.com with NNFMP; 05 Nov 2009 17:52:38 -0000 Received: from [127.0.0.1] by omp411.mail.mud.yahoo.com with NNFMP; 05 Nov 2009 17:52:38 -0000 X-Yahoo-Newman-Id: 591448.72722.bm@omp411.mail.mud.yahoo.com Received: (qmail 57797 invoked from network); 5 Nov 2009 17:52:38 -0000 Received: from adsl-67-125-158-26.dsl.irvnca.pacbell.net (andy@67.125.158.26 with plain) by smtp102.sbc.mail.sp1.yahoo.com with SMTP; 05 Nov 2009 09:52:38 -0800 PST X-Yahoo-SMTP: Z6xhxCCswBAlhcxjVNwaQtp4EKpLdTUUf5Nx_pGy81o- X-YMail-OSG: IrJXN_oVM1kLCUN5j6WFR_tAHqFoULjf7lXzjUDko3ubcEP0Hc8pNiACX_zfDQxpI52gC47EPAgaPN_ZKbsDdw3mYkWO07qk9i6h7ncZOn.kl6hWK0BY6_kcfESZr9h7FlmoyFIEyATCGGMq7qJOVk9y9GA0r5nj8YypRXMnpkddxVS4UjDfSMGtWBp5hgaLMKeba_KvmQ-- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4AF31133.6080207@netconfcentral.com> Date: Thu, 05 Nov 2009 09:53:55 -0800 From: Andy Bierman User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: NETCONF , NETMOD Working Group Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [Netconf] with-defaults definition of 'explicit mode' X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Nov 2009 17:52:18 -0000 Hi, I don't think this definition of explicit defaults matches what the NETMOD WG agreed to on the mailing list. o Explicitly set default data: Is default data that is set by a NETCONF client or other external management application/user by the way of an actual management operation to the value specified as its default in the data model schema. Some servers MAY treat explicitly set default data as simple default data, as they may not be able to differentiate between them. Data, that is set to a value other then its default value, is not default data, so its handling is outside the scope of this document. IMO, this definition is too loose for the standard. The NETMOD WG agreed that explicitly set means: o Explicitly set data: - any value set by the client - any value (other than the schema default) set by the server The leaf definition needs to match the 'explicit' retrieval mode. The 'schema default' concepts are not exactly the same as the 'explicitly set' concepts. A system-created leaf is visible in all retrieval modes. It MUST NOT be filtered out of an 'explicit' retrieval. It would never be filtered by a 'trim' retrieval, because s-c-stmt and default-stmt are incompatible. There must not be any 'unclassified' data, Every server MUST implement the 'explicit' mode the same way. This goes for 'basic' behavior, not just the leaf. Andy From mehmet.ersue@nsn.com Fri Nov 6 02:24:11 2009 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 509723A67EF for ; Fri, 6 Nov 2009 02:24:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[AWL=1.000, BAYES_00=-2.599, GB_I_INVITATION=-2, HTML_MESSAGE=0.001] 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 iZQi3+SEdnJH for ; Fri, 6 Nov 2009 02:24:09 -0800 (PST) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [93.183.12.31]) by core3.amsl.com (Postfix) with ESMTP id D00043A699E for ; Fri, 6 Nov 2009 02:24:08 -0800 (PST) Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id nA6AORcA015232 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 6 Nov 2009 11:24:27 +0100 Received: from demuexc024.nsn-intra.net (demuexc024.nsn-intra.net [10.159.32.11]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id nA6AORDf012912; Fri, 6 Nov 2009 11:24:27 +0100 Received: from DEMUEXC006.nsn-intra.net ([10.150.128.18]) by demuexc024.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Fri, 6 Nov 2009 11:24:26 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CA5ECB.511938F0" Date: Fri, 6 Nov 2009 11:24:24 +0100 Message-ID: <80A0822C5E9A4440A5117C2F4CD36A64125424@DEMUEXC006.nsn-intra.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: (Forward to attendees) Meeting invitation: netconf at IETF 76 Thread-Index: AcpevtQtNMfFMix+RNWrlFbY6K6IqAAA4aAg From: "Ersue, Mehmet (NSN - DE/Munich)" To: X-OriginalArrivalTime: 06 Nov 2009 10:24:26.0872 (UTC) FILETIME=[514AF780:01CA5ECB] Subject: [Netconf] FW: (Forward to attendees) Meeting invitation: netconf at IETF 76 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Nov 2009 10:24:11 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CA5ECB.511938F0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi All, =20 please use the information in the mail below for remote attendance at the NETCONF session in IETF 76. =20 People calling from outside of USA please Skype into the US toll free number or use the WebEx VoIP option (not particularly recommended).=20 Of course, if you only want to listen to the audio, you can use the regular IETF audio streaming, which will be available at http://videolab.uoregon.edu/events/ietf/ietf764.m3u . For jabber access please use: xmpp:netconf@jabber.ietf.org?join . Mehmet=20 =20 ________________________________ From: ext Alexa Morris [mailto:amorris@amsl.com]=20 Sent: Friday, November 06, 2009 9:55 AM To: ext Bert Wijnen (IETF); Ersue, Mehmet (NSN - DE/Munich) Cc: dromasca@avaya.com; Ron Bonica Subject: Fwd: (Forward to attendees) Meeting invitation: netconf at IETF 76 This is the invitation for the attendees.=20 Begin forwarded message: From: IETF Secretariat Date: November 6, 2009 12:42:19 AM PST To: amorris@amsl.com Subject: (Forward to attendees) Meeting invitation: netconf at IETF 76 Reply-To: amorris@amsl.com **** You can forward this email invitation to attendees ****=20 =09 Hello ,=20 =09 IETF Secretariat invites you to attend this online meeting.=20 =09 Topic: netconf at IETF 76=20 Date: Monday, November 9, 2009=20 Time: 3:00 pm, Japan Time (Tokyo, GMT+09:00)=20 Meeting Number: 962 045 886=20 Meeting Password: netconf=20 =09 =09 -------------------------------------------------------=20 To join the online meeting (Now from iPhones too!)=20 -------------------------------------------------------=20 1. Go to https://workgreen.webex.com/workgreen/j.php?ED=3D130140882&UID=3D0&PW=3DN= MGI5M jY1Y2U3&RT=3DMiM0OQ%3D%3D=20 2. Enter your name and email address.=20 3. Enter the meeting password: netconf=20 4. Click "Join Now".=20 =09 To view in other time zones or languages, please click the link: =09 https://workgreen.webex.com/workgreen/j.php?ED=3D130140882&UID=3D0&PW=3DN= MGI5M jY1Y2U3&ORT=3DMiM0OQ%3D%3D=20 =09 -------------------------------------------------------=20 To join the audio conference only=20 -------------------------------------------------------=20 To receive a call back, provide your phone number when you join the meeting, or call the number below and enter the access code.=20 Call-in toll-free number (US/Canada): 866-699-3239=20 Call-in toll number (US/Canada): 1-408-792-6300=20 Toll-free dialing restrictions: http://www.webex.com/pdf/tollfree_restrictions.pdf=20 =09 Access code:962 045 886=20 =09 -------------------------------------------------------=20 For assistance=20 -------------------------------------------------------=20 1. Go to https://workgreen.webex.com/workgreen/mc=20 2. On the left navigation bar, click "Support".=20 =09 You can contact me at:=20 amorris@amsl.com=20 1-510-492-4081=20 =09 To add this meeting to your calendar program (for example Microsoft Outlook), click this link:=20 =09 https://workgreen.webex.com/workgreen/j.php?ED=3D130140882&UID=3D0&ICS=3D= MI&LD =3D1&RD=3D2&ST=3D1&SHA2=3DKgy5-WmGEuRT7HcsIN2Oqq6kfcpRWYZjIUfbDiPdJtk=3D&= RT=3DMiM0OQ %3D%3D=20 =09 The playback of UCF (Universal Communications Format) rich media files requires appropriate players. To view this type of rich media files in the meeting, please check whether you have the players installed on your computer by going to https://workgreen.webex.com/workgreen/systemdiagnosis.php=20 =09 Sign up for a free trial of WebEx=20 http://www.webex.com/go/mcemfreetrial=20 =09 http://www.webex.com=20 =09 =09 =09 IMPORTANT NOTICE: This WebEx service includes a feature that allows audio and any documents and other materials exchanged or viewed during the session to be recorded. By joining this session, you automatically consent to such recordings. If you do not consent to the recording, do not join the session.=20 =09 ----------- Alexa Morris / Executive Director / IETF 48377 Fremont Blvd., Suite 117, Fremont, CA 94538 Phone: +1.510.492.4089 / Fax: +1.510.492.4001 Email: amorris@amsl.com Managed by Association Management Solutions (AMS) Forum Management, Meeting and Event Planning www.amsl.com ------_=_NextPart_001_01CA5ECB.511938F0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi=20 All,
 
please use the information in the mail below = for remote=20 attendance at the NETCONF session in IETF 76.
 
People calling from outside of USA please Skype into the US = toll free=20 number or use the WebEx VoIP option (not particularly recommended).=20
Of=20 course, if you only want to listen to the audio, you can use the regular = IETF=20 audio streaming, which will be available at http://video= lab.uoregon.edu/events/ietf/ietf764.m3u .
For=20 jabber access please use: xmpp:netconf@jabber.ietf.org?join=20 .

Mehmet
 

From: ext Alexa Morris = [mailto:amorris@amsl.com]=20
Sent: Friday, November 06, 2009 9:55 AM
To: ext = Bert Wijnen=20 (IETF); Ersue, Mehmet (NSN - DE/Munich)
Cc: = dromasca@avaya.com; Ron=20 Bonica
Subject: Fwd: (Forward to attendees) Meeting = invitation:=20 netconf at IETF 76

This is the invitation for the attendees. 

Begin forwarded message:

From: IETF = Secretariat <messenger@webex.com>
Date: November 6, = 2009 12:42:19=20 AM PST
To: amorris@amsl.com
Subject: (Forward = to attendees)=20 Meeting invitation: netconf at IETF 76
Reply-To: = amorris@amsl.com

**** = You can=20 forward this email invitation to attendees ****

Hello , =

IETF=20 Secretariat invites you to attend this online meeting.

Topic: = netconf=20 at IETF 76
Date: Monday, November 9, 2009
Time: 3:00 pm, Japan = Time=20 (Tokyo, GMT+09:00)
Meeting Number: 962 045 886
Meeting = Password:=20 netconf =


-------------------------------------------------------=20
To join the online meeting (Now from iPhones too!)=20
-------------------------------------------------------
1. Go = to https://workgreen.webex.com/workgreen/j.php?ED=3D13014088= 2&UID=3D0&PW=3DNMGI5MjY1Y2U3&RT=3DMiM0OQ%3D%3D=20
2. Enter your name and email address.
3. Enter the meeting = password:=20 netconf
4. Click "Join Now".

To view in other time zones = or=20 languages, please click the link:
https://workgreen.webex.com/workgreen/j.php?ED=3D13014088= 2&UID=3D0&PW=3DNMGI5MjY1Y2U3&ORT=3DMiM0OQ%3D%3D=20

-------------------------------------------------------
To = join=20 the audio conference only=20
-------------------------------------------------------
To = receive a=20 call back, provide your phone number when you join the meeting, or = call the=20 number below and enter the access code.
Call-in toll-free number=20 (US/Canada): 866-699-3239
Call-in toll number (US/Canada): = 1-408-792-6300=20
Toll-free dialing restrictions: http://www.webex.com/pdf/tollfree_restrictions.pdf =

Access code:962 045 886=20

------------------------------------------------------- =
For=20 assistance
------------------------------------------------------- =
1.=20 Go to https://workgreen.webex.com/workgreen/mc
2. On = the left=20 navigation bar, click "Support".

You can contact me at:
amorris@amsl.com =
1-510-492-4081=20

To add this meeting to your calendar program (for example = Microsoft=20 Outlook), click this link:
https://workgreen.webex.com/workgreen/j.php?ED=3D13014088= 2&UID=3D0&ICS=3DMI&LD=3D1&RD=3D2&ST=3D1&SHA2=3DKg= y5-WmGEuRT7HcsIN2Oqq6kfcpRWYZjIUfbDiPdJtk=3D&RT=3DMiM0OQ%3D%3D=20

The playback of UCF (Universal Communications Format) rich = media files=20 requires appropriate players. To view this type of rich media files in = the=20 meeting, please check whether you have the players installed on your = computer=20 by going to https://workgreen.webex.com/workgreen/systemdiagnosis.php= =20

Sign up for a free trial of WebEx
http://www.webex.com/go/mcemfreetrial

http://www.webex.com =



IMPORTANT NOTICE: This WebEx service includes a = feature that=20 allows audio and any documents and other materials exchanged or viewed = during=20 the session to be recorded. By joining this session, you automatically = consent=20 to such recordings. If you do not consent to the recording, do not = join the=20 session.

-----------
Alexa Morris / Executive Director / IETF
48377 = Fremont=20 Blvd., Suite 117, Fremont, CA  94538
Phone: +1.510.492.4089 / = Fax:=20 +1.510.492.4001
Email: amorris@amsl.com

Managed by=20 Association Management Solutions (AMS)
Forum Management, Meeting and = Event=20 Planning
www.amsl.com <http://www.amsl.com/>

------_=_NextPart_001_01CA5ECB.511938F0-- From mehmet.ersue@nsn.com Fri Nov 6 18:42:32 2009 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6180A3A6A13 for ; Fri, 6 Nov 2009 18:42:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[AWL=-0.100, BAYES_00=-2.599] 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 Uy66pjQCNlen for ; Fri, 6 Nov 2009 18:42:31 -0800 (PST) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [93.183.12.31]) by core3.amsl.com (Postfix) with ESMTP id 061B83A679F for ; Fri, 6 Nov 2009 18:42:30 -0800 (PST) Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id nA72gqVT026069 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Sat, 7 Nov 2009 03:42:52 +0100 Received: from demuexc023.nsn-intra.net (demuexc023.nsn-intra.net [10.150.128.36]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id nA72gqgU019106; Sat, 7 Nov 2009 03:42:52 +0100 Received: from DEMUEXC006.nsn-intra.net ([10.150.128.18]) by demuexc023.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Sat, 7 Nov 2009 03:42:52 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Sat, 7 Nov 2009 03:42:47 +0100 Message-ID: <80A0822C5E9A4440A5117C2F4CD36A641255CB@DEMUEXC006.nsn-intra.net> In-Reply-To: <20091102211232.GA4455@elstar.local> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Netconf] draft-ietf-netconf-monitoring-09 last call comments fromjs Thread-Index: AcpcAUYoCv+8tNcBQfSExHxKbsSiUQDUGABQ References: <085091CB2CA14E4B8B163FFC37C84E9D1A9F69CD@zcarhxm0.corp.nortel.com><80A0822C5E9A4440A5117C2F4CD36A64031460@DEMUEXC006.nsn-intra.net> <20091102211232.GA4455@elstar.local> From: "Ersue, Mehmet (NSN - DE/Munich)" To: "Juergen Schoenwaelder" , X-OriginalArrivalTime: 07 Nov 2009 02:42:52.0015 (UTC) FILETIME=[0048E7F0:01CA5F54] Subject: Re: [Netconf] draft-ietf-netconf-monitoring-09 last call comments fromjs X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Nov 2009 02:42:32 -0000 Hi Juergen, thank you for the thorough review. It seems that we need another update for the monitoring draft. > : [...] The > : capabilities of a NETCONF server may change over time. =20 > However, once > : a NETCONF server has announced its capabilities in the > : message, the capabilities for that session MUST NOT=20 > change. A server > : MUST reply with a 'capabilities-changed' error if the=20 > client sends a > : request which is affected by a modified capability. A server MAY > : choose to send 'capabilities-changed' as the response to=20 > any request > : other than if its capabilities has changed. >=20 > It seems to me that it is not the job of the monitoring document to > establish rules how NETCONF works. I suggest to remove this text and > to include such text in RFC 4741bis instead. True, it is not the job of the monitoring document to establish rules=20 how NETCONF works. I agree to remove this text and to add it to 4741bis. > : Schema: A machine readable data model definition. The schema is > : independent of which data modeling language is used=20 > for the data > : model. >=20 > I have trouble to understand the second sentence. Every machine > readable data model is written in a specific format. So how can the > schema be format specific and at the same time independent? Perhaps > the second sentence should just be removed. The schema is dependent on the data modeling language. I agree, that the second sentence should be removed. > : To provide clients the ability to manage locked resources lock > : information is provided for each ConfigurationDataStore instance. >=20 > I have no clue what this ConfigurationDataStore instance is. Additionally the sentence is somehow mishapen. > : For YANG data models, the format is one of "yang" or "yin". >=20 > I am concerned about interoperability here. I prefer that the "yang" > format is required and "yin" can be provided optionally. Otherwise, > you require that all management applications have two parsers instead > of one. I think it is a good proposal to have "yang" format required and=20 "yin" optional. This can reduce the implementation cost. =20 : .... : .... > I am badly missing description statements here. In general, it seems > that many description statements leave out details that are explained > in section 2. In SMIv2 land, it was considered good practice to have > all normative texts in the data model so that the text is there once > extracted from the RFC. I believe we should follow this practice and > move most of the text from section 2.1 into description clauses. This > also avoids any potential inconsistencies. I think we should avoid having the RFC text and the normative YANG module=20 as redundant. I agree that the YANG module has to be self-explanatory and=20 complete from the management information definition POV where the RFC text=20 should contain explanations and additional text for the YANG module. =20 I agree also with Randy that content relevant to management should be in the=20 YANG module. However, if we describe the monitoring approach or operational=20 characteristics this might not be subject to management. =20 Cheers, Mehmet From mehmet.ersue@nsn.com Fri Nov 6 19:27:19 2009 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2BDC928B23E for ; Fri, 6 Nov 2009 19:27:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.69 X-Spam-Level: X-Spam-Status: No, score=-2.69 tagged_above=-999 required=5 tests=[AWL=-0.091, BAYES_00=-2.599] 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 0g6Zez07n6qr for ; Fri, 6 Nov 2009 19:27:18 -0800 (PST) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [93.183.12.31]) by core3.amsl.com (Postfix) with ESMTP id 54D3628C0F7 for ; Fri, 6 Nov 2009 19:27:16 -0800 (PST) Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id nA73RagH024667 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Sat, 7 Nov 2009 04:27:36 +0100 Received: from demuexc023.nsn-intra.net (demuexc023.nsn-intra.net [10.150.128.36]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id nA73RY8f012694; Sat, 7 Nov 2009 04:27:36 +0100 Received: from DEMUEXC006.nsn-intra.net ([10.150.128.18]) by demuexc023.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Sat, 7 Nov 2009 04:27:34 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Sat, 7 Nov 2009 04:27:31 +0100 Message-ID: <80A0822C5E9A4440A5117C2F4CD36A641255CD@DEMUEXC006.nsn-intra.net> In-Reply-To: <80A0822C5E9A4440A5117C2F4CD36A640E0B05@DEMUEXC006.nsn-intra.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Netconf] WGLC for draft-ietf-netconf-monitoring-09 Thread-Index: AcpM8tHJxxCBJN7QSL2T+SkMdEFmTwAABoPAASNfCEAB/DAFYAF5SWsA References: <085091CB2CA14E4B8B163FFC37C84E9D1A9F69CD@zcarhxm0.corp.nortel.com><80A0822C5E9A4440A5117C2F4CD36A64031460@DEMUEXC006.nsn-intra.net> <80A0822C5E9A4440A5117C2F4CD36A640E0B05@DEMUEXC006.nsn-intra.net> From: "Ersue, Mehmet (NSN - DE/Munich)" To: , "ext Mark Scott" X-OriginalArrivalTime: 07 Nov 2009 03:27:34.0297 (UTC) FILETIME=[3F0CA890:01CA5F5A] Subject: Re: [Netconf] WGLC for draft-ietf-netconf-monitoring-09 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Nov 2009 03:27:19 -0000 Hi Mark, please find below some additional comments. Some of=20 them have been brought up already earlier. Chapter 1. Introduction s/adjust their capabilities/adjust their knowledge of the server's capabilities/ Chapter 1.1. Definition of Terms The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [Key words for use in RFCs to Indicate Requirement Levels]. Please use the regular RFC template which says: The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14, [RFC2119]. Chapter 2. Data Model to Monitor NETCONF IIRC we wanted to change "urn:ietf:params:xml:ns:netconf:state" to "urn:ietf:params:xml:ns:netconf:monitor:", or? The consensus was not=20 to have a version number. Mehmet =20 > -----Original Message----- > From: netconf-bounces@ietf.org=20 > [mailto:netconf-bounces@ietf.org] On Behalf Of ext Ersue,=20 > Mehmet (NSN - DE/Munich) > Sent: Friday, October 30, 2009 4:11 PM > To: netconf@ietf.org > Subject: Re: [Netconf] WGLC for draft-ietf-netconf-monitoring-09 >=20 >=20 > Hi All, >=20 > this is a friendly reminder for the WGLC of the=20 > draft "NETCONF monitoring draft", which runs=20 > until November 2. >=20 > I would like to ask all to give the monitoring=20 > draft a chance and send your comments to the=20 > NETCONF maillist. >=20 > We are planning to bring the draft in the NETCONF=20 > session at IETF 76 to the next stage. So, please=20 > help to get it stable. >=20 > Thank you. >=20 > Mehmet > =20 >=20 > > -----Original Message----- > > From: netconf-bounces@ietf.org=20 > > [mailto:netconf-bounces@ietf.org] On Behalf Of ext Ersue,=20 > > Mehmet (NSN - DE/Munich) > > Sent: Tuesday, October 20, 2009 2:36 PM > > To: netconf@ietf.org > > Subject: [Netconf] WGLC for draft-ietf-netconf-monitoring-09 > >=20 > >=20 > > Dear NETCONF WG,=20 > >=20 > > we had a good discussion on the NETCONF monitoring=20 > > draft since the last WGLC in July.=20 > >=20 > > The draft Mark and Martin submitted solves the issues=20 > > raised on the maillist and introduces the YANG model=20 > > as normative. The new version of the draft appears to=20 > > be stable for a final WGLC before we go one step further.=20 > >=20 > > With this mail we start a new WGLC for the NETCONF=20 > > monitoring draft, which is planned to publish as a=20 > > Proposed Standard RFC. The WGLC will run until=20 > > November 2, 2009.=20 > >=20 > >=20 > > All WG members PLEASE REVIEW the draft again and send=20 > > your comments to the NETCONF maillist: > >=20 > > http://tools.ietf.org/html/draft-ietf-netconf-monitoring-09 > >=20 > > Thank you.=20 > >=20 > > Mehmet > > =20 > >=20 > > > -----Original Message----- > > > From: netconf-bounces@ietf.org=20 > > > [mailto:netconf-bounces@ietf.org] On Behalf Of ext Mark Scott > > > Sent: Wednesday, October 14, 2009 7:47 PM > > > To: netconf@ietf.org > > > Subject: [Netconf] FW: New Version Notification=20 > > > fordraft-ietf-netconf-monitoring-09 > > >=20 > > > Hello, > > >=20 > > > A new version (v9) of the NETCONF Monitoring Schema draft has=20 > > > been posted. > > >=20 > > > This version addresses mailing list comments received on v8: > > > - reversion of 'session-type' to 'transport' > > > - element naming consistency. All lowerCamelCase names have=20 > > > been converted to 'hyphen-delimited' or=20 > > > 'netconf-style-naming' as it is sometimes referred to on the=20 > > > ML. E.g. 'sessionType' -> 'session-type'. This change=20 > > > impacts both the draft text and yang module. =20 > > > - operation updated: > > > - now has only one mandatory parameter, 'identifier' > > > - updated negative responses, including the rpc=20 > > > operation description in yang module > > > - comments added to the yang module indicating that the=20 > > > definition of 'session-id' is consistent with 4741bis=20 > > > 'session-id-type' and could be imported from that pending=20 > > > RFC. Similar for 'netconf-datastore-type'. This was in=20 > > > favour of adding further dependencies and delays by waiting=20 > > > for 4741bis to complete. > > > =20 > > > Please direct any comments on this version to the mailing list. > > >=20 > > > cheers, > > > Mark > > >=20 > > >=20 > > > -----Original Message----- > > > From: IETF I-D Submission Tool [mailto:idsubmission@ietf.org]=20 > > > Sent: Wednesday, October 14, 2009 1:22 PM > > > To: Scott, Mark (CAR:2N00) > > > Cc: mbj@tail-f.com > > > Subject: New Version Notification for=20 > > > draft-ietf-netconf-monitoring-09=20 > > >=20 > > >=20 > > > A new version of I-D, draft-ietf-netconf-monitoring-09.txt=20 > > > has been successfuly submitted by Mark Scott and posted to=20 > > > the IETF repository. > > >=20 > > > Filename: draft-ietf-netconf-monitoring > > > Revision: 09 > > > Title: NETCONF Monitoring Schema > > > Creation_date: 2009-10-14 > > > WG ID: netconf > > > Number_of_pages: 30 > > >=20 > > > Abstract: > > > This document defines a NETCONF data model to be used to=20 > monitor the > > > NETCONF protocol. The monitoring data model includes information > > > about NETCONF datastores, sessions, locks and statistics.=20 > This data > > > facilitates the management of a NETCONF server. This=20 > document also > > > defines methods for NETCONF clients to discover data models=20 > > supported > > > by a NETCONF server and defines a new NETCONF=20 > operation > > > to retrieve them. > > > =20 > > > =20 > > >=20 > > >=20 > > > The IETF Secretariat. > > >=20 > > >=20 > > > _______________________________________________ > > > Netconf mailing list > > > Netconf@ietf.org > > > https://www.ietf.org/mailman/listinfo/netconf > > >=20 > > _______________________________________________ > > Netconf mailing list > > Netconf@ietf.org > > https://www.ietf.org/mailman/listinfo/netconf > >=20 > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf >=20 From mehmet.ersue@nsn.com Sat Nov 7 22:50:49 2009 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2D48628C111 for ; Sat, 7 Nov 2009 22:50:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.682 X-Spam-Level: X-Spam-Status: No, score=-2.682 tagged_above=-999 required=5 tests=[AWL=-0.084, BAYES_00=-2.599, HTML_MESSAGE=0.001] 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 n4NgKRhi0Z1j for ; Sat, 7 Nov 2009 22:50:48 -0800 (PST) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [93.183.12.31]) by core3.amsl.com (Postfix) with ESMTP id 0088328C10C for ; Sat, 7 Nov 2009 22:50:47 -0800 (PST) Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id nA86p76l013612 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Sun, 8 Nov 2009 07:51:07 +0100 Received: from demuexc022.nsn-intra.net (demuexc022.nsn-intra.net [10.150.128.35]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id nA86p7wB024259; Sun, 8 Nov 2009 07:51:07 +0100 Received: from DEMUEXC006.nsn-intra.net ([10.150.128.18]) by demuexc022.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Sun, 8 Nov 2009 07:51:07 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CA603F.D8B659D8" Date: Sun, 8 Nov 2009 07:51:05 +0100 Message-ID: <80A0822C5E9A4440A5117C2F4CD36A64125603@DEMUEXC006.nsn-intra.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Slides for the NETCONF WG session at IETF 76 Thread-Index: AcpgP9ciRC+jhGgBTfy3bFXJX2QhQQ== From: "Ersue, Mehmet (NSN - DE/Munich)" To: X-OriginalArrivalTime: 08 Nov 2009 06:51:07.0435 (UTC) FILETIME=[D90F5FB0:01CA603F] Subject: [Netconf] Slides for the NETCONF WG session at IETF 76 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Nov 2009 06:50:49 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CA603F.D8B659D8 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi All, please find the slides for the NETCONF WG session at IETF 76 at: https://datatracker.ietf.org/meeting/76/materials.html There are no slides for 4741bis draft. We will go through the=20 issues in the issue tracker, see: http://trac.tools.ietf.org/wg/netconf/trac/wiki/Issues_4741bis=20 Cheers, Mehmet ------_=_NextPart_001_01CA603F.D8B659D8 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Slides for the NETCONF WG session at IETF 76

Hi All,

please find the slides for the = NETCONF WG session at IETF 76 at:
https://datatracker.ietf.org/meeting/76/materials.html

There are no slides for 4741bis = draft. We will go through the
issues in the issue tracker, = see:
<= U>http://trac.tools.ietf.org/wg/netconf/trac/wiki/Issues_4= 741bis

Cheers,
Mehmet

------_=_NextPart_001_01CA603F.D8B659D8-- From j.schoenwaelder@jacobs-university.de Sun Nov 8 12:56:02 2009 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2BBF628C0D7 for ; Sun, 8 Nov 2009 12:56:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.924 X-Spam-Level: X-Spam-Status: No, score=-1.924 tagged_above=-999 required=5 tests=[AWL=0.325, BAYES_00=-2.599, HELO_EQ_DE=0.35] 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 epsvr7ChaizB for ; Sun, 8 Nov 2009 12:56:01 -0800 (PST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id F3DF63A67EF for ; Sun, 8 Nov 2009 12:56:00 -0800 (PST) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 37FEAC000D for ; Sun, 8 Nov 2009 21:56:26 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius2.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 5vwkEkeQcffF; Sun, 8 Nov 2009 21:56:25 +0100 (CET) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 4DBE9C000C; Sun, 8 Nov 2009 21:56:25 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 18072DA795B; Sun, 8 Nov 2009 21:56:25 +0100 (CET) Date: Sun, 8 Nov 2009 21:56:24 +0100 From: Juergen Schoenwaelder To: netconf@ietf.org Message-ID: <20091108205624.GA15523@elstar.local> Mail-Followup-To: netconf@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.20 (2009-06-14) Subject: [Netconf] additional netconf (4741bis) issues X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Nov 2009 20:56:02 -0000 Hi, I have a file where I collected some additional 4741bis issues. Its getting time to get it on the table (and I am happy to do the edits if people agree on the issues). * clarify: copy-config('running', 'candidate') == commit() copy-config('candidate', 'running') == discard-changes() * clarify any changes to 'running' must fail (check which error applies) while a commit is in progress * clarify The handling of default data is implementation specific. Some implementations may choose to suppress default data while others may choose to always report default data while yet some other implementations may suppress default data as long as it was not explicitely set. A NETCONF extension allows to work with these implementation differences. * clarify examples Make sure the message-id is in a proper namespace in all the examples. Note that attributes are not in the default namespace, so one has to be explicit: vs. * incorporate capabilities text from the netconf-monitoring draft The capabilities of a NETCONF server may change over time. However, once a NETCONF server has announced its capabilities in the message, the capabilities for that session MUST NOT change. A server MUST reply with a 'capabilities-changed' error if the client sends a request which is affected by a modified capability. A server MAY choose to send 'capabilities-changed' as the response to any request other than if its capabilities has changed. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From mehmet.ersue@nsn.com Sun Nov 8 18:35:13 2009 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E5BDD3A67BD for ; Sun, 8 Nov 2009 18:35:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.676 X-Spam-Level: X-Spam-Status: No, score=-2.676 tagged_above=-999 required=5 tests=[AWL=-0.077, BAYES_00=-2.599] 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 Ia0lUcGHl59r for ; Sun, 8 Nov 2009 18:35:13 -0800 (PST) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [93.183.12.32]) by core3.amsl.com (Postfix) with ESMTP id A6AF83A6901 for ; Sun, 8 Nov 2009 18:35:12 -0800 (PST) Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd001.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id nA92ZZRp032442 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Mon, 9 Nov 2009 03:35:35 +0100 Received: from demuexc024.nsn-intra.net (demuexc024.nsn-intra.net [10.159.32.11]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id nA92ZZVm023203 for ; Mon, 9 Nov 2009 03:35:35 +0100 Received: from DEMUEXC006.nsn-intra.net ([10.150.128.18]) by demuexc024.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Mon, 9 Nov 2009 03:35:35 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 9 Nov 2009 03:35:33 +0100 Message-ID: <80A0822C5E9A4440A5117C2F4CD36A641256BE@DEMUEXC006.nsn-intra.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [OPS-AREA] OPS Area open office hours in Hiroshima Thread-Index: AcpXHQm+0Cafz0RVS+CiSZG/lC1u2QJyCDGQ From: "Ersue, Mehmet (NSN - DE/Munich)" To: X-OriginalArrivalTime: 09 Nov 2009 02:35:35.0491 (UTC) FILETIME=[50EC2130:01CA60E5] Subject: [Netconf] FW: [OPS-AREA] OPS Area open office hours in Hiroshima X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Nov 2009 02:35:14 -0000 =20 FYI Cheers, Mehmet -----Original Message----- From: ops-area-bounces@ietf.org [mailto:ops-area-bounces@ietf.org] On Behalf Of ext Romascanu, Dan (Dan) Sent: Tuesday, October 27, 2009 4:49 PM To: OPS Area (E-mail); ops-chairs@ietf.org Subject: [OPS-AREA] OPS Area open office hours in Hiroshima The OPS Area will hold the Open Office Hours at the Hiroshima IETF meeting on Thursday 11/12 between 15:00 and 16:30 in the IESG breakout room which is Room Castleview 2. Please join us for any OPS Area or IETF business issues that you would like to talk with us.=20 OPS-CHAIRS - please distribute this message to your WG's.=20 Thanks and Regards, Ron and Dan _______________________________________________ OPS-AREA mailing list OPS-AREA@ietf.org https://www.ietf.org/mailman/listinfo/ops-area From mbj@tail-f.com Mon Nov 9 00:54:47 2009 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6EAB43A6B14 for ; Mon, 9 Nov 2009 00:54:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.973 X-Spam-Level: X-Spam-Status: No, score=-1.973 tagged_above=-999 required=5 tests=[AWL=0.073, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] 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 LEnyAXJH230e for ; Mon, 9 Nov 2009 00:54:46 -0800 (PST) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id F14E23A6B10 for ; Mon, 9 Nov 2009 00:54:44 -0800 (PST) Received: from localhost (c213-100-167-236.swipnet.se [213.100.167.236]) by mail.tail-f.com (Postfix) with ESMTPSA id 90F48616001; Mon, 9 Nov 2009 09:47:45 +0100 (CET) Date: Mon, 09 Nov 2009 09:47:45 +0100 (CET) Message-Id: <20091109.094745.20601006.mbj@tail-f.com> To: j.schoenwaelder@jacobs-university.de From: Martin Bjorklund In-Reply-To: <20091108205624.GA15523@elstar.local> References: <20091108205624.GA15523@elstar.local> X-Mailer: Mew version 6.2.51 on Emacs 22.2 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: netconf@ietf.org Subject: Re: [Netconf] additional netconf (4741bis) issues X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Nov 2009 08:54:47 -0000 Juergen Schoenwaelder wrote: > Hi, > > I have a file where I collected some additional 4741bis issues. Its > getting time to get it on the table (and I am happy to do the edits if > people agree on the issues). > > * clarify: > > copy-config('running', 'candidate') == commit() This is not quite correct. A copy-config() does not count as a confirming commit. > copy-config('candidate', 'running') == discard-changes() Ok. > * clarify > > any changes to 'running' must fail (check which error applies) while > a commit is in progress No, since you are allowed to do more changes through a new confirming commit: Note that any commit operation, including a commit which introduces additional changes to the configuration, will serve as a confirming commit. Unless we want to change that of course... > * clarify > > The handling of default data is implementation specific. Some > implementations may choose to suppress default data while others may > choose to always report default data while yet some other > implementations may suppress default data as long as it was not > explicitely set. A NETCONF extension allows to work with these > implementation differences. Ok. We just agreed that 4741bis should say that with-defaults SHOULD be implemented. > * clarify examples > > Make sure the message-id is in a proper namespace in all the > examples. Note that attributes are not in the default namespace, so > one has to be explicit: > > xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"> > > > vs. > > xmlns:nc="urn:ietf:params:xml:ns:netconf:base:1.0"> > No this is not correct. The default namespace doesn't even apply to attributes. And in the XSD, attributeFormDefault is "unqualified", which means that local attributes do not have prefixes. Confusing? A simple concept like "namespace" surely must be easy to explain - see http://www.rpbourret.com/xml/NamespacesFAQ.htm :) > * incorporate capabilities text from the netconf-monitoring draft > > The > capabilities of a NETCONF server may change over time. However, once > a NETCONF server has announced its capabilities in the > message, the capabilities for that session MUST NOT change. A server > MUST reply with a 'capabilities-changed' error if the client sends a > request which is affected by a modified capability. A server MAY > choose to send 'capabilities-changed' as the response to any request > other than if its capabilities has changed. Ok. It is still not clear if 'capabilities-changed' should be a new error-tag (makes the protocol incompatible), or an error-app-tag (works, but the protocol is not an "app"), or maybe error-info (also works, but seems a bit convoluted). /martin From mbj@tail-f.com Mon Nov 9 01:06:54 2009 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 576333A6842; Mon, 9 Nov 2009 01:06:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.975 X-Spam-Level: X-Spam-Status: No, score=-1.975 tagged_above=-999 required=5 tests=[AWL=0.071, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] 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 ihs+wptUqgA3; Mon, 9 Nov 2009 01:06:53 -0800 (PST) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id 89C6A3A659B; Mon, 9 Nov 2009 01:06:53 -0800 (PST) Received: from localhost (c213-100-167-236.swipnet.se [213.100.167.236]) by mail.tail-f.com (Postfix) with ESMTPSA id 46B8C616001; Mon, 9 Nov 2009 10:07:19 +0100 (CET) Date: Mon, 09 Nov 2009 10:07:16 +0100 (CET) Message-Id: <20091109.100716.96917148.mbj@tail-f.com> To: andy@netconfcentral.com From: Martin Bjorklund In-Reply-To: <4AF31133.6080207@netconfcentral.com> References: <4AF31133.6080207@netconfcentral.com> X-Mailer: Mew version 6.2.51 on Emacs 22.2 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: netconf@ietf.org, netmod@ietf.org Subject: Re: [Netconf] with-defaults definition of 'explicit mode' X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Nov 2009 09:06:54 -0000 Andy Bierman wrote: > Hi, > > I don't think this definition of explicit defaults matches what > the NETMOD WG agreed to on the mailing list. > > o Explicitly set default data: Is default data that is set by a > NETCONF client or other external management application/user by > the way of an actual management operation to the value specified > as its default in the data model schema. Some servers MAY treat > explicitly set default data as simple default data, as they may > not be able to differentiate between them. > Data, that is set to a value other then its default value, is not > default data, so its handling is outside the scope of this > document. > > IMO, this definition is too loose for the standard. > The NETMOD WG agreed that explicitly set means: > o Explicitly set data: > - any value set by the client > - any value (other than the schema default) set by the server I think the definition is ok - note that it defines the term "explicitly set default data", not "explicitly set data". However, I do not understand: Some servers MAY treat explicitly set default data as simple default data, as they may not be able to differentiate between them. What is "simple default data"? Can this sentence be removed? Also, the last sentence ("Data, that is set ..." does not belong in the definition of the term "explicitly set default data"). /martin From mbj@tail-f.com Mon Nov 9 01:30:41 2009 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 692573A68EC for ; Mon, 9 Nov 2009 01:30:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[AWL=0.069, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] 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 Tw7FZmhjUBUi for ; Mon, 9 Nov 2009 01:30:40 -0800 (PST) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id 4347C28C1F1 for ; Mon, 9 Nov 2009 01:30:39 -0800 (PST) Received: from localhost (c213-100-167-236.swipnet.se [213.100.167.236]) by mail.tail-f.com (Postfix) with ESMTPSA id A8DC5616002 for ; Mon, 9 Nov 2009 10:31:04 +0100 (CET) Date: Mon, 09 Nov 2009 10:31:03 +0100 (CET) Message-Id: <20091109.103103.127078221.mbj@tail-f.com> To: netconf@ietf.org From: Martin Bjorklund X-Mailer: Mew version 6.2.51 on Emacs 22.2 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: [Netconf] Comments on draft-ietf-netconf-with-defaults-04 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Nov 2009 09:30:41 -0000 Hi, Here are some comments on this document. 1.1 --- External management application/user can reach the device e.g. via the NETCONF, CLI, SNMP, GUI. Can you rephrase the definition where this sentence occurs? It seems out-of-place. 1.1 --- In addition the following terms are defined in RFC 4741 and are not redefined here: o application I don't think it is defined in 4741, and you are using the term "management application". 1.2 --- OLD: o trim: Values are not reported if they match the default. NEW: (Is this a correct interpretation?) o trim: Values are not reported if they match the default value as specified in the data model schema. 2.5 --- OLD: A new XML child element is added to the method-name element. This is the element that indicates the type of the operation e.g. , or . NEW: A new XML child element is added to the , , and rpc operations. 4. -- s/Data Model XSD/XML Schema for the with-defaults capability/ 8. -- // for the uri data type import ietf-netconf { prefix nc; } remove the comment; it is wrong. 8. -- Since you want other operations to also add the with-defaults parameter, would it make sense to place it in a reusable grouping? grouping with-defaults-parameters { leaf with-defaults { type with-defaults-mode; } } augment /nc:get-config/nc:input { uses with-defaults-parameters; } General ------- Can we change the parameter 'basic' to 'basic-mode'? /martin From lhotka@cesnet.cz Mon Nov 9 01:58:33 2009 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A0C3C3A6B23 for ; Mon, 9 Nov 2009 01:58:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.25 X-Spam-Level: X-Spam-Status: No, score=-1.25 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904] 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 ADEkYC4xvzra for ; Mon, 9 Nov 2009 01:58:33 -0800 (PST) Received: from office2.cesnet.cz (office2.cesnet.cz [195.113.144.244]) by core3.amsl.com (Postfix) with ESMTP id CDD6C3A6953 for ; Mon, 9 Nov 2009 01:58:32 -0800 (PST) Received: from [133.93.113.127] (host-113-127.meeting.ietf.org [133.93.113.127]) by office2.cesnet.cz (Postfix) with ESMTP id 95AB3D800F7 for ; Mon, 9 Nov 2009 10:58:56 +0100 (CET) From: Ladislav Lhotka To: NETCONF WG Content-Type: text/plain Organization: CESNET Date: Mon, 09 Nov 2009 18:58:52 +0900 Message-Id: <1257760732.3555.25.camel@missotis> Mime-Version: 1.0 X-Mailer: Evolution 2.26.1 Content-Transfer-Encoding: 7bit Subject: [Netconf] warnings X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Nov 2009 09:58:33 -0000 Hi, I am wondering: was the idea behind warnings to use them for sucessfully completed operations? If not, warnings don't make much sense to me. I guess warnings could be useful together with a capability that allows for confirming a previously issued operation which the server classifies as potentially harmful, like changing the IP address that is used for the current session. Other than that, warnings belong to notifications. Lada -- Ladislav Lhotka, CESNET PGP Key ID: E74E8C0C From mbj@tail-f.com Mon Nov 9 02:07:17 2009 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 25CCC3A67FB for ; Mon, 9 Nov 2009 02:07:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.979 X-Spam-Level: X-Spam-Status: No, score=-1.979 tagged_above=-999 required=5 tests=[AWL=0.067, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] 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 F5Wg5ymhpSHQ for ; Mon, 9 Nov 2009 02:07:16 -0800 (PST) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id 43DF43A696D for ; Mon, 9 Nov 2009 02:07:16 -0800 (PST) Received: from localhost (c213-100-167-236.swipnet.se [213.100.167.236]) by mail.tail-f.com (Postfix) with ESMTPSA id E1A3A616001; Mon, 9 Nov 2009 11:07:40 +0100 (CET) Date: Mon, 09 Nov 2009 11:07:40 +0100 (CET) Message-Id: <20091109.110740.66657803.mbj@tail-f.com> To: lhotka@cesnet.cz From: Martin Bjorklund In-Reply-To: <1257760732.3555.25.camel@missotis> References: <1257760732.3555.25.camel@missotis> X-Mailer: Mew version 6.2.51 on Emacs 22.2 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: netconf@ietf.org Subject: Re: [Netconf] warnings X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Nov 2009 10:07:17 -0000 Ladislav Lhotka wrote: > Hi, > > I am wondering: was the idea behind warnings to use them for sucessfully > completed operations? If not, warnings don't make much sense to me. > > I guess warnings could be useful together with a capability that allows > for confirming a previously issued operation which the server classifies > as potentially harmful, like changing the IP address that is used for > the current session. I agree that this would be useful - "If you make this change your users will experience severe service disruption - are you sure you want to continue?". But that can never have been the intention with the current protocol. Hmm.. this could probably be added in a backwards compatible way, but I'm not sure it is worth it. /martin From mbj@tail-f.com Mon Nov 9 04:13:05 2009 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 148043A6B3A for ; Mon, 9 Nov 2009 04:13:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.985 X-Spam-Level: X-Spam-Status: No, score=-1.985 tagged_above=-999 required=5 tests=[AWL=0.061, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] 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 07wrLVxesgEh for ; Mon, 9 Nov 2009 04:13:04 -0800 (PST) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id 4463F3A6B38 for ; Mon, 9 Nov 2009 04:13:04 -0800 (PST) Received: from localhost (c213-100-167-236.swipnet.se [213.100.167.236]) by mail.tail-f.com (Postfix) with ESMTPSA id 3EA79616001 for ; Mon, 9 Nov 2009 13:13:26 +0100 (CET) Date: Mon, 09 Nov 2009 13:13:25 +0100 (CET) Message-Id: <20091109.131325.241209342.mbj@tail-f.com> To: netconf@ietf.org From: Martin Bjorklund X-Mailer: Mew version 6.2.51 on Emacs 22.2 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: [Netconf] 4741bis (011) - duplicate edit-config modifications X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Nov 2009 12:13:05 -0000 Hi, This issue was brought up in the NETCONF session today. The problem is what happens in the following case, when mtu is a leaf: eth0 100 1500 The proposal was that the result is implementation specific, (just as in SNMP when the same variable occurs twice in a SET PDU). But Wes and Balazs argued that this a data model issue, and thus does not belong in 4741bis. For example, if mtu were a leaf-list, the XML above is perfectly fine. I will close this issue for 4741bis, unless noone objects. /martin From mbj@tail-f.com Mon Nov 9 04:52:21 2009 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CF6853A6B03 for ; Mon, 9 Nov 2009 04:52:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.987 X-Spam-Level: X-Spam-Status: No, score=-1.987 tagged_above=-999 required=5 tests=[AWL=0.059, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] 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 VjssCFvDm3na for ; Mon, 9 Nov 2009 04:52:21 -0800 (PST) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id ED1443A6B2F for ; Mon, 9 Nov 2009 04:52:20 -0800 (PST) Received: from localhost (c213-100-167-236.swipnet.se [213.100.167.236]) by mail.tail-f.com (Postfix) with ESMTPSA id 4A79D616004 for ; Mon, 9 Nov 2009 13:52:46 +0100 (CET) Date: Mon, 09 Nov 2009 13:52:45 +0100 (CET) Message-Id: <20091109.135245.24918919.mbj@tail-f.com> To: netconf@ietf.org From: Martin Bjorklund In-Reply-To: <20090430.160428.110485974.mbj@tail-f.com> References: <20090430.160428.110485974.mbj@tail-f.com> X-Mailer: Mew version 6.2.51 on Emacs 22.2 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: [Netconf] 4741bis - multiple namespaces X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Nov 2009 12:52:21 -0000 Hi, http://trac.tools.ietf.org/wg/netconf/trac/wiki/Issues_4741bis#issue-006 This was discussed at the last IETF session (in Stockholm). The consensus in the room was to remove the paragraph: Martin Bjorklund wrote: > Hi, > > Section 7.1 says: > > If the configuration is available in multiple formats, such as > XML and text, an XML namespace can be used to specify which > format is desired. In the following example, the client uses a > specific element () in a specific namespace to > indicate to the server the desire to receive the configuration in > an alternative format. The server may support any number of > distinct formats or views into the configuration data, with the > client using the parameter to select between them. > > It looks like namespaces are used for two different purposes; > different data models and different formats. This leads to some > questions: > > Can the same be achieved with XPath? > > If no filter is specified, what should the server return - *all* > namespaces (mulitple data models, multiple formats), or all > namespaces for *some* format? How would you get all data for the > text format? > > IMO this feature looks broken. > > > Does anyone implement this? Can we remove this paragraph? Unless anyone objects, I will now remove it. /martin From mbj@tail-f.com Mon Nov 9 04:54:45 2009 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 108C13A6998 for ; Mon, 9 Nov 2009 04:54:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.988 X-Spam-Level: X-Spam-Status: No, score=-1.988 tagged_above=-999 required=5 tests=[AWL=0.058, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] 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 tyAu5QSS8fJE for ; Mon, 9 Nov 2009 04:54:44 -0800 (PST) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id 414093A67D2 for ; Mon, 9 Nov 2009 04:54:44 -0800 (PST) Received: from localhost (c213-100-167-236.swipnet.se [213.100.167.236]) by mail.tail-f.com (Postfix) with ESMTPSA id BC888616001 for ; Mon, 9 Nov 2009 13:48:55 +0100 (CET) Date: Mon, 09 Nov 2009 13:48:55 +0100 (CET) Message-Id: <20091109.134855.198534070.mbj@tail-f.com> To: netconf@ietf.org From: Martin Bjorklund In-Reply-To: References: <20090430.160141.138853286.mbj@tail-f.com> <49F9C24F.6090702@netconfcentral.com> X-Mailer: Mew version 6.2.51 on Emacs 22.2 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: [Netconf] 4741bis - error-path X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Nov 2009 12:54:45 -0000 Hi, http://trac.tools.ietf.org/wg/netconf/trac/wiki/Issues_4741bis#issue-003 I propose the following text for error-path. It also (partly) covers Andy's issue in http://www.ietf.org/mail-archive/web/netconf/current/msg04630.html. error-path: Contains the absolute XPath [2] expression identifying the element path to the node that is associated with the error being reported in a particular rpc-error element. This element will not be present if no appropriate payload element or data store node can be associated with a particular error condition. The XPath expression is interpreted in the following context: * The set of namespace declarations are those in scope on the rpc-error element. * The set of variable bindings is empty. * The function library is the core function library. The context node depends on the node associated with the error being reported: * If a payload element can be associated with the error, the context node is the rpc request's document node (i.e. the "rpc" element). * Otherwise, the context node is the root of all data models, i.e. the node which has the top-level nodes from all data models as children. The example on page 19 will also use an error-path starting from a data model node: /t:top/t:interface[t:name="Ethernet0/0"]/t:mtu /martin From mbj@tail-f.com Mon Nov 9 05:52:15 2009 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6831D3A6973 for ; Mon, 9 Nov 2009 05:52:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.99 X-Spam-Level: X-Spam-Status: No, score=-1.99 tagged_above=-999 required=5 tests=[AWL=0.056, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] 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 V6X120kmm+Gt for ; Mon, 9 Nov 2009 05:52:14 -0800 (PST) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id 031293A6B5F for ; Mon, 9 Nov 2009 05:52:14 -0800 (PST) Received: from localhost (c213-100-167-236.swipnet.se [213.100.167.236]) by mail.tail-f.com (Postfix) with ESMTPSA id 16F37616001 for ; Mon, 9 Nov 2009 14:52:40 +0100 (CET) Date: Mon, 09 Nov 2009 14:52:39 +0100 (CET) Message-Id: <20091109.145239.111899012.mbj@tail-f.com> To: netconf@ietf.org From: Martin Bjorklund X-Mailer: Mew version 6.2.51 on Emacs 22.2 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: [Netconf] 4741bis (007) - return from XPath filters X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Nov 2009 13:52:15 -0000 Hi, http://trac.tools.ietf.org/wg/netconf/trac/wiki/Issues_4741bis#issue-007 This issue was discussed at the NETCONF session today. The question is what the resulting XML from an XPath filter looks like. For example, with this data model: list interface { key name; ... leaf mtu { ... } } What should the expression: select="/interface/mtu" return? 1. (no keys) 1500 1500 2. (keys) eth0 1500 eth2 1500 At least two implementations (mine and Andy's) return the keys, as in alternative 2. I suggest we add this to 8.9.1: The response message contains the subtrees selected by the filter expression. For each such subtree, the path from the data model root node down to the subtree, including any elements or attributes necessary to uniquely identify the subtree, are included in the response message. This is slightly different from how subtree filtering works. Compare these filters, with a data model where 'user' is a list with key 'name': and which look very similar. The first one returns: fred 2 but the second one doesn't return any keys (which is not very useful...) 2 Andy commented that his code returns the keys also in the subtree filter case. I'm not convinced the current text on subtree filtering allows this, but maybe we should clarify that key nodes MAY be added to the response message in subtree filtering. Since the text on subtree filtering says: The server does not need to utilize any data-model-specific semantics during processing, we cannot say that the keys MUST be added, so a client that needs the keys will still have to ask for them. /martin From phil@juniper.net Mon Nov 9 06:07:38 2009 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EEE4328C0F1 for ; Mon, 9 Nov 2009 06:07:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.548 X-Spam-Level: X-Spam-Status: No, score=-6.548 tagged_above=-999 required=5 tests=[AWL=0.051, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 4ye4zAL8Zmnt for ; Mon, 9 Nov 2009 06:07:38 -0800 (PST) Received: from exprod7og118.obsmtp.com (exprod7og118.obsmtp.com [64.18.2.8]) by core3.amsl.com (Postfix) with ESMTP id 10F293A6B66 for ; Mon, 9 Nov 2009 06:07:38 -0800 (PST) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob118.postini.com ([64.18.6.12]) with SMTP ID DSNKSvgiPhlbf3z6U/85PU36Au6KDp108wYD@postini.com; Mon, 09 Nov 2009 06:08:04 PST Received: from p-emfe01-sac.jnpr.net (66.129.254.72) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server id 8.1.375.2; Mon, 9 Nov 2009 05:50:48 -0800 Received: from p-emlb02-sac.jnpr.net ([66.129.254.47]) by p-emfe01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Mon, 9 Nov 2009 05:50:48 -0800 Received: from emailsmtp55.jnpr.net ([172.24.18.132]) by p-emlb02-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Mon, 9 Nov 2009 05:50:47 -0800 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp55.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Mon, 9 Nov 2009 05:50:46 -0800 Received: from idle.juniper.net (idleski.juniper.net [172.25.4.26]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id nA9Dojj62332; Mon, 9 Nov 2009 05:50:45 -0800 (PST) (envelope-from phil@juniper.net) Received: from idle.juniper.net (localhost [127.0.0.1]) by idle.juniper.net (8.13.8/8.13.8) with ESMTP id nA9DbVYX001460; Mon, 9 Nov 2009 13:37:31 GMT (envelope-from phil@idle.juniper.net) Message-ID: <200911091337.nA9DbVYX001460@idle.juniper.net> To: Martin Bjorklund In-Reply-To: <20091109.094745.20601006.mbj@tail-f.com> Date: Mon, 9 Nov 2009 08:37:31 -0500 From: Phil Shafer X-OriginalArrivalTime: 09 Nov 2009 13:50:46.0506 (UTC) FILETIME=[A35E74A0:01CA6143] MIME-Version: 1.0 Content-Type: text/plain Cc: netconf@ietf.org Subject: Re: [Netconf] additional netconf (4741bis) issues X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Nov 2009 14:07:39 -0000 Martin Bjorklund writes: >Ok. We just agreed that 4741bis should say that with-defaults SHOULD >be implemented. I strongly object to with-defaults being SHOULD. 2119 says: 3. SHOULD This word, or the adjective "RECOMMENDED", mean that there may exist valid reasons in particular circumstances to ignore a particular item, but the full implications must be understood and carefully weighed before choosing a different course. I don't see the implementation of use of W-D as being sufficiently important to hit this bar. It's a "nice to have" feature, but not a SHOULD. In particular, there are multiple implementations of NETCONF working in the real world at this moment that do not have this feature and are not significantly harmed. For data model that contain the sufficient default values, an implementation may never need to use W-D. Thanks, Phil From lhotka@cesnet.cz Mon Nov 9 06:09:01 2009 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 492D028C11D for ; Mon, 9 Nov 2009 06:09:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.25 X-Spam-Level: X-Spam-Status: No, score=-1.25 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904] 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 ZqlPwiVDpnSx for ; Mon, 9 Nov 2009 06:09:00 -0800 (PST) Received: from office2.cesnet.cz (office2.cesnet.cz [195.113.144.244]) by core3.amsl.com (Postfix) with ESMTP id 5471B28C11E for ; Mon, 9 Nov 2009 06:09:00 -0800 (PST) Received: from [133.93.113.127] (host-113-127.meeting.ietf.org [133.93.113.127]) by office2.cesnet.cz (Postfix) with ESMTP id 8D5FDD800F1; Mon, 9 Nov 2009 15:09:25 +0100 (CET) From: Ladislav Lhotka To: Martin Bjorklund In-Reply-To: <20091109.131325.241209342.mbj@tail-f.com> References: <20091109.131325.241209342.mbj@tail-f.com> Content-Type: text/plain; charset="UTF-8" Organization: CESNET Date: Mon, 09 Nov 2009 23:09:21 +0900 Message-Id: <1257775761.3555.67.camel@missotis> Mime-Version: 1.0 X-Mailer: Evolution 2.26.1 Content-Transfer-Encoding: 8bit Cc: netconf@ietf.org Subject: Re: [Netconf] 4741bis (011) - duplicate edit-config modifications X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Nov 2009 14:09:01 -0000 Martin Bjorklund píše v Po 09. 11. 2009 v 13:13 +0100: > Hi, > > This issue was brought up in the NETCONF session today. > > The problem is what happens in the following case, when mtu is a leaf: > > > eth0 > 100 > 1500 > > > The proposal was that the result is implementation specific, (just as > in SNMP when the same variable occurs twice in a SET PDU). > > But Wes and Balazs argued that this a data model issue, and thus does > not belong in 4741bis. For example, if mtu were a leaf-list, the XML > above is perfectly fine. It was me, not Balazs. :-) I didn't agree with the formulation that the result is implementation specific - every NETCONF implementation should pass this data to the "Content Layer" because it is outside its scope. I don't know why this example is so specific - the same could be said about an edit-config that uses unknown elements. It should suffice to say that NETCONF doesn't care about data contents of the PDUs as long as they satisfy some minimum requirements on well-formedness. Lada > > I will close this issue for 4741bis, unless noone objects. > > > /martin > > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf -- Ladislav Lhotka, CESNET PGP Key ID: E74E8C0C From reid@snmp.com Mon Nov 9 07:11:07 2009 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0CE043A69A1 for ; Mon, 9 Nov 2009 07:11:07 -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 mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hTZBQ8QqV20Z for ; Mon, 9 Nov 2009 07:11:05 -0800 (PST) Received: from mailbox.snmp.com (mailbox.snmp.com [192.147.142.80]) by core3.amsl.com (Postfix) with ESMTP id 567773A6B72 for ; Mon, 9 Nov 2009 07:11:05 -0800 (PST) Received: from adminfs.snmp.com (adminfs.snmp.com [192.147.142.39]) by mailbox.snmp.com (8.9.3p2-20030922/m.0080228) with ESMTP id KAA05196; Mon, 9 Nov 2009 10:11:30 -0500 (EST) Received: from snmp.com (LOCALHOST.snmp.com [127.0.0.1]) by adminfs.snmp.com (8.9.3p2-20030922/snmpclient.mc-990525) with ESMTP id KAA25807; Mon, 9 Nov 2009 10:11:29 -0500 (EST) Message-Id: <200911091511.KAA25807@adminfs.snmp.com> To: Martin Bjorklund From: David Reid In-reply-to: Your message of Mon, 09 Nov 2009 14:52:39 +0100. <20091109.145239.111899012.mbj@tail-f.com> Date: Mon, 09 Nov 2009 10:11:29 -0500 Sender: reid@snmp.com Cc: netconf@ietf.org Subject: Re: [Netconf] 4741bis (007) - return from XPath filters X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: David Reid List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Nov 2009 15:11:07 -0000 > I suggest we add this to 8.9.1: > > The response message contains the subtrees selected by the filter > expression. For each such subtree, the path from the data model > root node down to the subtree, including any elements or > attributes necessary to uniquely identify the subtree, are > included in the response message. > I think the keys should be included, so I agree with the proposed text above. > > This is slightly different from how subtree filtering works. > > Andy commented that his code returns the keys also in the subtree > filter case. I'm not convinced the current text on subtree filtering > allows this, but maybe we should clarify that key nodes MAY be added > to the response message in subtree filtering. Our implementation also returns the keys, which I think is the only useful approach, but maybe not correct according the the current spec. I support the proposed clarification saying key nodes MAY be added. -David Reid From mbj@tail-f.com Mon Nov 9 07:19:47 2009 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 343BC3A6B7F for ; Mon, 9 Nov 2009 07:19:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.992 X-Spam-Level: X-Spam-Status: No, score=-1.992 tagged_above=-999 required=5 tests=[AWL=0.054, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] 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 nqR8Xo35L-Bc for ; Mon, 9 Nov 2009 07:19:46 -0800 (PST) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id 2F4B33A6B14 for ; Mon, 9 Nov 2009 07:19:39 -0800 (PST) Received: from localhost (c213-100-167-236.swipnet.se [213.100.167.236]) by mail.tail-f.com (Postfix) with ESMTPSA id 8336B616001 for ; Mon, 9 Nov 2009 16:20:05 +0100 (CET) Date: Mon, 09 Nov 2009 16:20:05 +0100 (CET) Message-Id: <20091109.162005.97616231.mbj@tail-f.com> To: netconf@ietf.org From: Martin Bjorklund X-Mailer: Mew version 6.2.51 on Emacs 22.2 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: [Netconf] 4741bis (009) - partial-operation X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Nov 2009 15:19:47 -0000 Hi, http://trac.tools.ietf.org/wg/netconf/trac/wiki/Issues_4741bis#issue-009 The proposal is that we should remove the error-tag partial-operation (and associated error-info elements; ok-element, err-element, and noop-element). As currently defined, this feature seems broken. The error-info elements have wrong type (QName), and the idea appears to be that this rpc-error should be returned instead of when an edit-config succeeds. For background, see: http://www.ietf.org/mail-archive/web/netconf/current/msg04623.html http://ops.ietf.org/lists/netconf/netconf.2006/msg00115.html http://ops.ietf.org/lists/netconf/netconf.2006/msg00108.html If anyone objects to removing this error, we need a proposal for how to make it work. /martin From lhotka@cesnet.cz Mon Nov 9 07:34:08 2009 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 714A23A68D2 for ; Mon, 9 Nov 2009 07:34:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.25 X-Spam-Level: X-Spam-Status: No, score=-1.25 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904] 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 Y7hF8ztrVIsG for ; Mon, 9 Nov 2009 07:34:07 -0800 (PST) Received: from office2.cesnet.cz (office2.cesnet.cz [195.113.144.244]) by core3.amsl.com (Postfix) with ESMTP id 9AD583A6838 for ; Mon, 9 Nov 2009 07:34:07 -0800 (PST) Received: from [133.93.113.127] (host-113-127.meeting.ietf.org [133.93.113.127]) by office2.cesnet.cz (Postfix) with ESMTP id B782AD800F5 for ; Mon, 9 Nov 2009 16:34:32 +0100 (CET) From: Ladislav Lhotka To: netconf@ietf.org In-Reply-To: <20091109.145239.111899012.mbj@tail-f.com> References: <20091109.145239.111899012.mbj@tail-f.com> Content-Type: text/plain; charset="UTF-8" Organization: CESNET Date: Tue, 10 Nov 2009 00:34:23 +0900 Message-Id: <1257780863.3555.131.camel@missotis> Mime-Version: 1.0 X-Mailer: Evolution 2.26.1 Content-Transfer-Encoding: 8bit Subject: Re: [Netconf] 4741bis (007) - return from XPath filters X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Nov 2009 15:34:08 -0000 Martin Bjorklund píše v Po 09. 11. 2009 v 14:52 +0100: > I suggest we add this to 8.9.1: > > The response message contains the subtrees selected by the filter > expression. For each such subtree, the path from the data model > root node down to the subtree, including any elements or > attributes necessary to uniquely identify the subtree, are > included in the response message. Hmm, how do you recognize such elements or attributes? NETCONF has no notion of list keys, so there may be multiple ways how to satisfy this requirement. For instance, in a user database both uid and username will be unique although only one of them will be used as the list key in YANG. It's true that the XPath capablity is underspecified but this will be hard to fix because specification of database queries belongs to the "Content" layer. Lada > > -- Ladislav Lhotka, CESNET PGP Key ID: E74E8C0C From mbj@tail-f.com Mon Nov 9 07:41:26 2009 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 83FA93A6B67 for ; Mon, 9 Nov 2009 07:41:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.994 X-Spam-Level: X-Spam-Status: No, score=-1.994 tagged_above=-999 required=5 tests=[AWL=0.052, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] 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 0UkapZIobFVF for ; Mon, 9 Nov 2009 07:41:25 -0800 (PST) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id B5A1D3A684A for ; Mon, 9 Nov 2009 07:41:25 -0800 (PST) Received: from localhost (c213-100-167-236.swipnet.se [213.100.167.236]) by mail.tail-f.com (Postfix) with ESMTPSA id C71CF616001; Mon, 9 Nov 2009 16:41:51 +0100 (CET) Date: Mon, 09 Nov 2009 16:41:51 +0100 (CET) Message-Id: <20091109.164151.152756359.mbj@tail-f.com> To: lhotka@cesnet.cz From: Martin Bjorklund In-Reply-To: <1257780863.3555.131.camel@missotis> References: <20091109.145239.111899012.mbj@tail-f.com> <1257780863.3555.131.camel@missotis> X-Mailer: Mew version 6.2.51 on Emacs 22.2 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=utf-8 Content-Transfer-Encoding: base64 Cc: netconf@ietf.org Subject: Re: [Netconf] 4741bis (007) - return from XPath filters X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Nov 2009 15:41:26 -0000 TGFkaXNsYXYgTGhvdGthIDxsaG90a2FAY2VzbmV0LmN6PiB3cm90ZToNCj4gTWFydGluIEJqb3Jr bHVuZCBww63FoWUgdiBQbyAwOS4gMTEuIDIwMDkgdiAxNDo1MiArMDEwMDoNCj4gPiBJIHN1Z2dl c3Qgd2UgYWRkIHRoaXMgdG8gOC45LjE6DQo+ID4gDQo+ID4gICAgIFRoZSByZXNwb25zZSBtZXNz YWdlIGNvbnRhaW5zIHRoZSBzdWJ0cmVlcyBzZWxlY3RlZCBieSB0aGUgZmlsdGVyDQo+ID4gICAg IGV4cHJlc3Npb24uICBGb3IgZWFjaCBzdWNoIHN1YnRyZWUsIHRoZSBwYXRoIGZyb20gdGhlIGRh dGEgbW9kZWwNCj4gPiAgICAgcm9vdCBub2RlIGRvd24gdG8gdGhlIHN1YnRyZWUsIGluY2x1ZGlu ZyBhbnkgZWxlbWVudHMgb3INCj4gPiAgICAgYXR0cmlidXRlcyBuZWNlc3NhcnkgdG8gdW5pcXVl bHkgaWRlbnRpZnkgdGhlIHN1YnRyZWUsIGFyZQ0KPiA+ICAgICBpbmNsdWRlZCBpbiB0aGUgcmVz cG9uc2UgbWVzc2FnZS4NCj4gDQo+IEhtbSwgaG93IGRvIHlvdSByZWNvZ25pemUgc3VjaCBlbGVt ZW50cyBvciBhdHRyaWJ1dGVzPyBORVRDT05GIGhhcyBubw0KPiBub3Rpb24gb2YgbGlzdCBrZXlz LCBzbyB0aGVyZSBtYXkgYmUgbXVsdGlwbGUgd2F5cyBob3cgdG8gc2F0aXNmeSB0aGlzDQo+IHJl cXVpcmVtZW50LiBGb3IgaW5zdGFuY2UsIGluIGEgdXNlciBkYXRhYmFzZSBib3RoIHVpZCBhbmQg dXNlcm5hbWUgd2lsbA0KPiBiZSB1bmlxdWUgYWx0aG91Z2ggb25seSBvbmUgb2YgdGhlbSB3aWxs IGJlIHVzZWQgYXMgdGhlIGxpc3Qga2V5IGluDQo+IFlBTkcuDQoNClN1cmUsIHRoYXQgd2lsbCBi ZSBkYXRhIG1vZGVsIGRlcGVuZGVudC4gIElzIHRoYXQgYSBwcm9ibGVtPw0KDQoNCi9tYXJ0aW4N Cg== From mbj@tail-f.com Mon Nov 9 07:43:26 2009 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 528A728C15C for ; Mon, 9 Nov 2009 07:43:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.995 X-Spam-Level: X-Spam-Status: No, score=-1.995 tagged_above=-999 required=5 tests=[AWL=0.051, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] 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 N4-+3lAyaJoR for ; Mon, 9 Nov 2009 07:43:25 -0800 (PST) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id 869993A698D for ; Mon, 9 Nov 2009 07:43:25 -0800 (PST) Received: from localhost (c213-100-167-236.swipnet.se [213.100.167.236]) by mail.tail-f.com (Postfix) with ESMTPSA id 8FA73616002 for ; Mon, 9 Nov 2009 16:43:49 +0100 (CET) Date: Mon, 09 Nov 2009 16:43:49 +0100 (CET) Message-Id: <20091109.164349.228269389.mbj@tail-f.com> To: netconf@ietf.org From: Martin Bjorklund X-Mailer: Mew version 6.2.51 on Emacs 22.2 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: [Netconf] 4741bis (010) - namespace wildcarding X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Nov 2009 15:43:26 -0000 Hi, http://trac.tools.ietf.org/wg/netconf/trac/wiki/Issues_4741bis#issue-010 This issue was discussed at IETF75 in Stockholm. It has been noted on the ML that the Namespace Selection part of subtree filtering needs to be fixed (that is part of issue 008). This proposal is that if the null namespace is used in a subtree filter, it should be interpreted as a wildcard, for example: could return: ... ... Comments? /martin From phil@juniper.net Mon Nov 9 07:47:54 2009 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 40D0128C16F for ; Mon, 9 Nov 2009 07:47:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.549 X-Spam-Level: X-Spam-Status: No, score=-6.549 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 OZpvGgChM3AN for ; Mon, 9 Nov 2009 07:47:53 -0800 (PST) Received: from exprod7og103.obsmtp.com (exprod7og103.obsmtp.com [64.18.2.159]) by core3.amsl.com (Postfix) with ESMTP id 76AB328C174 for ; Mon, 9 Nov 2009 07:47:52 -0800 (PST) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob103.postini.com ([64.18.6.12]) with SMTP ID DSNKSvg5vz4LycjOJteA5ulJbMSbE4lkxCRA@postini.com; Mon, 09 Nov 2009 07:48:19 PST Received: from p-emfe01-sac.jnpr.net (66.129.254.72) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server id 8.1.375.2; Mon, 9 Nov 2009 07:45:14 -0800 Received: from p-emlb01-sac.jnpr.net ([66.129.254.46]) by p-emfe01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Mon, 9 Nov 2009 07:45:14 -0800 Received: from emailsmtp55.jnpr.net ([172.24.18.132]) by p-emlb01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Mon, 9 Nov 2009 07:45:14 -0800 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp55.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Mon, 9 Nov 2009 07:45:13 -0800 Received: from idle.juniper.net (idleski.juniper.net [172.25.4.26]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id nA9FjBj45523; Mon, 9 Nov 2009 07:45:11 -0800 (PST) (envelope-from phil@juniper.net) Received: from idle.juniper.net (localhost [127.0.0.1]) by idle.juniper.net (8.13.8/8.13.8) with ESMTP id nA9FVv8S002813; Mon, 9 Nov 2009 15:31:57 GMT (envelope-from phil@idle.juniper.net) Message-ID: <200911091531.nA9FVv8S002813@idle.juniper.net> To: Martin Bjorklund In-Reply-To: <20091109.135245.24918919.mbj@tail-f.com> Date: Mon, 9 Nov 2009 10:31:57 -0500 From: Phil Shafer X-OriginalArrivalTime: 09 Nov 2009 15:45:13.0305 (UTC) FILETIME=[A04CD490:01CA6153] MIME-Version: 1.0 Content-Type: text/plain Cc: netconf@ietf.org Subject: Re: [Netconf] 4741bis - multiple namespaces X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Nov 2009 15:47:54 -0000 Martin Bjorklund writes: >Unless anyone objects, I will now remove it. I object. The intent is to return all nodes associated with a given namespace. For example, if a data model defines five "top-level" containers, I want to get all five containers with out getting other data. Similarly, if the data model is just text, there's no element to filter on, so we need a mechanism for retrieving that data. The XPath equivalent would be "prefix:*" or "*" with prefix's namespace as the current namespace. Thanks, Phil From phil@juniper.net Mon Nov 9 07:54:47 2009 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1240A3A677D for ; Mon, 9 Nov 2009 07:54:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.55 X-Spam-Level: X-Spam-Status: No, score=-6.55 tagged_above=-999 required=5 tests=[AWL=0.049, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 fi9rhvJfEMjd for ; Mon, 9 Nov 2009 07:54:46 -0800 (PST) Received: from exprod7og110.obsmtp.com (exprod7og110.obsmtp.com [64.18.2.173]) by core3.amsl.com (Postfix) with ESMTP id 555A33A6B74 for ; Mon, 9 Nov 2009 07:54:37 -0800 (PST) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob110.postini.com ([64.18.6.12]) with SMTP ID DSNKSvg7TEfjnoPwcrV18TNVQrYhr8wNIGIg@postini.com; Mon, 09 Nov 2009 07:55:04 PST Received: from p-emfe01-sac.jnpr.net (66.129.254.72) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server id 8.1.375.2; Mon, 9 Nov 2009 07:51:44 -0800 Received: from p-emlb01-sac.jnpr.net ([66.129.254.46]) by p-emfe01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Mon, 9 Nov 2009 07:51:44 -0800 Received: from emailsmtp55.jnpr.net ([172.24.18.132]) by p-emlb01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Mon, 9 Nov 2009 07:51:44 -0800 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp55.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Mon, 9 Nov 2009 07:51:43 -0800 Received: from idle.juniper.net (idleski.juniper.net [172.25.4.26]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id nA9Fpcj56277; Mon, 9 Nov 2009 07:51:42 -0800 (PST) (envelope-from phil@juniper.net) Received: from idle.juniper.net (localhost [127.0.0.1]) by idle.juniper.net (8.13.8/8.13.8) with ESMTP id nA9FcNHZ002893; Mon, 9 Nov 2009 15:38:23 GMT (envelope-from phil@idle.juniper.net) Message-ID: <200911091538.nA9FcNHZ002893@idle.juniper.net> To: Martin Bjorklund In-Reply-To: <20091109.110740.66657803.mbj@tail-f.com> Date: Mon, 9 Nov 2009 10:38:23 -0500 From: Phil Shafer X-OriginalArrivalTime: 09 Nov 2009 15:51:43.0475 (UTC) FILETIME=[88DC0C30:01CA6154] MIME-Version: 1.0 Content-Type: text/plain Cc: netconf@ietf.org Subject: Re: [Netconf] warnings X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Nov 2009 15:54:47 -0000 Martin Bjorklund writes: >Hmm.. this could probably be added in a backwards compatible way, but >I'm not sure it is worth it. Warnings are meant to give information that the user or client might need, but won't stop the device from doing as told. For example, if you are installing a software image that requires a reboot, a warning can announce this to the user. What NETCONF got wrong IMHO is that warnings are a classification of errors, so attempting to give a warning is really giving an error, which isn't acceptable. We had and as distinct tags at one point, but collapsed the two ideas into a meaningless mush. As it sits, warnings are unusable. Can we repair them? Thanks, Phil From andy@netconfcentral.com Mon Nov 9 08:14:48 2009 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 28BE33A6816 for ; Mon, 9 Nov 2009 08:14:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.111 X-Spam-Level: X-Spam-Status: No, score=-2.111 tagged_above=-999 required=5 tests=[AWL=0.487, BAYES_00=-2.599, UNPARSEABLE_RELAY=0.001] 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 p9Ag8lFhLSTD for ; Mon, 9 Nov 2009 08:14:47 -0800 (PST) Received: from smtp101.sbc.mail.mud.yahoo.com (smtp101.sbc.mail.mud.yahoo.com [68.142.198.200]) by core3.amsl.com (Postfix) with SMTP id 4CA503A6A29 for ; Mon, 9 Nov 2009 08:14:43 -0800 (PST) Received: (qmail 73512 invoked from network); 9 Nov 2009 16:15:07 -0000 Received: from adsl-67-125-158-26.dsl.irvnca.pacbell.net (andy@67.125.158.26 with plain) by smtp101.sbc.mail.mud.yahoo.com with SMTP; 09 Nov 2009 08:15:07 -0800 PST X-Yahoo-SMTP: Z6xhxCCswBAlhcxjVNwaQtp4EKpLdTUUf5Nx_pGy81o- X-YMail-OSG: lccXHqMVM1ldmuJ0YkdIgOwNY0_qf7s_C8jluxjzPyHoU9ZJT3HK2yzPXT2UKQG8kV.wtXAiHreSOfSq5BbOLHO0iCo4VuR9KvyU8V2c9u8LZ0ocxx4lGpaM2piBpRgeB96tWa_a9mRHjS9A.yUxhmY48b8yTQSewYEx7rO2DutcAabb9mfRtXCld.g_WSCz6hNiBodf8VwabInpzdmWHHUXQIaCCk6r_LXxD7Fb_KVe0TsOGtoytnznV5a8MtLR X-Yahoo-Newman-Property: ymail-3 Message-ID: <4AF83F9D.70105@netconfcentral.com> Date: Mon, 09 Nov 2009 08:13:17 -0800 From: Andy Bierman User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: Phil Shafer References: <200911091337.nA9DbVYX001460@idle.juniper.net> In-Reply-To: <200911091337.nA9DbVYX001460@idle.juniper.net> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: netconf@ietf.org Subject: Re: [Netconf] additional netconf (4741bis) issues X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Nov 2009 16:14:48 -0000 Phil Shafer wrote: > Martin Bjorklund writes: >> Ok. We just agreed that 4741bis should say that with-defaults SHOULD >> be implemented. > > I strongly object to with-defaults being SHOULD. 2119 says: > > 3. SHOULD This word, or the adjective "RECOMMENDED", mean that there > may exist valid reasons in particular circumstances to ignore a > particular item, but the full implications must be understood and > carefully weighed before choosing a different course. > > I don't see the implementation of use of W-D as being sufficiently > important to hit this bar. It's a "nice to have" feature, but not > a SHOULD. In particular, there are multiple implementations of > NETCONF working in the real world at this moment that do not have > this feature and are not significantly harmed. For data model that > contain the sufficient default values, an implementation may never > need to use W-D. > The same could be said for YANG. There are NETCONF implementations that don't use YANG. So what? The issue for the IETF to decide SHOULD/MUST is whether a client SHOULD/MUST be able to retrieve all server values. IMO, this is a SHOULD requirement. We have already established that the server knows all the default leafs, even when the meta-data is incomplete so the client cannot deduce the values. If you only ship data models that never have any YANG defaults, then you can explain to your customers that the SHOULD doesn't apply to you. > Thanks, > Phil Andy From mbj@tail-f.com Mon Nov 9 08:15:12 2009 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 527413A680A for ; Mon, 9 Nov 2009 08:15:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.996 X-Spam-Level: X-Spam-Status: No, score=-1.996 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] 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 sSeBhWeVzHw0 for ; Mon, 9 Nov 2009 08:15:11 -0800 (PST) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id 7236F3A677D for ; Mon, 9 Nov 2009 08:15:11 -0800 (PST) Received: from localhost (c213-100-167-236.swipnet.se [213.100.167.236]) by mail.tail-f.com (Postfix) with ESMTPSA id 8C07A616001; Mon, 9 Nov 2009 17:15:37 +0100 (CET) Date: Mon, 09 Nov 2009 17:15:37 +0100 (CET) Message-Id: <20091109.171537.197959890.mbj@tail-f.com> To: phil@juniper.net From: Martin Bjorklund In-Reply-To: <200911091531.nA9FVv8S002813@idle.juniper.net> References: <20091109.135245.24918919.mbj@tail-f.com> <200911091531.nA9FVv8S002813@idle.juniper.net> X-Mailer: Mew version 6.2.51 on Emacs 22.2 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: netconf@ietf.org Subject: Re: [Netconf] 4741bis - multiple namespaces X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Nov 2009 16:15:12 -0000 Phil Shafer wrote: > Martin Bjorklund writes: > >Unless anyone objects, I will now remove it. > > I object. The intent is to return all nodes associated with a given > namespace. For example, if a data model defines five "top-level" > containers, I want to get all five containers with out getting other > data. Hmm... what does this have to do with the paragraph about multiple formats? What you ask for is covered by the text on subtree filtering. > Similarly, if the data model is just text, there's no element > to filter on, so we need a mechanism for retrieving that data. Well, the paragraph indicates that even in the text case, there has to be an XML element ( in the example). My concern is that the paragraph seems to indicate that NETCONF has the ability to select which format to use - XML or text - for a given data model. But what the example really does is just normal subtree filter on two different elements in two different namespaces. The paragraph also talks about different views of the data. This is an interesting topic. For example, I think we want to support the case that a device implements a native data model (acme-foo.yang), and a standard model (ietf-foo.yang). The standard model might be just a transform into - or different view of - the native data model. [I realize that this has been discussed before on the ML...]. Now, when you do a w/o any filters, what do you get? /martin From andy@netconfcentral.com Mon Nov 9 08:16:09 2009 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 358133A686E for ; Mon, 9 Nov 2009 08:16:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.123 X-Spam-Level: X-Spam-Status: No, score=-2.123 tagged_above=-999 required=5 tests=[AWL=0.475, BAYES_00=-2.599, UNPARSEABLE_RELAY=0.001] 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 53tvdNLXJZlD for ; Mon, 9 Nov 2009 08:16:08 -0800 (PST) Received: from smtp107.sbc.mail.mud.yahoo.com (smtp107.sbc.mail.mud.yahoo.com [68.142.198.105]) by core3.amsl.com (Postfix) with SMTP id 576E03A684A for ; Mon, 9 Nov 2009 08:16:08 -0800 (PST) Received: (qmail 3678 invoked from network); 9 Nov 2009 16:16:34 -0000 Received: from adsl-67-125-158-26.dsl.irvnca.pacbell.net (andy@67.125.158.26 with plain) by smtp107.sbc.mail.mud.yahoo.com with SMTP; 09 Nov 2009 08:16:34 -0800 PST X-Yahoo-SMTP: Z6xhxCCswBAlhcxjVNwaQtp4EKpLdTUUf5Nx_pGy81o- X-YMail-OSG: y5w.FpIVM1niKmGrldQcRNZbQuceNch2iMqVjxf9bwu87A51964F3ZF8gd5mNbMQ.tqOC36pf41b5j2y_00jDObevrJF3tXZ_7n0Nb2Yx5NcIGVwyUlDgpBnYarbQI9fPV9iUM1eim79pCVarCnQSrVvuwsIw6bMEz_uf0sT0rNyKSitQXtDW5kHrK5ZlfqrAsemFMbMBAuAZRvq7f3sgCDDu2BUbquBOvCMMT3ftjCXfP7gQe7PuC29cds4ZouLMkiqw4ncT3G_ZLrzDbXPVTziPiYoQ2FwzmL862DX0ou3G_f4jKTn36EB67ffC0VTPid7i9rEZ3vGDudP.uCRQ_kDMcUrk8reG7zOIVcNE8anhanNA2IeUaZgnfMR6PuiemmlVm8Q6Wgk2PSVsT.rjHGsS0PUr8Ih4NMKhF0MFEiTnKyMvAktyQJBOb0vG9ZItM8WHnnQSNyt3CAoaoGQksY1qReo90sUjc1TXew4ROBLXlGLgKdB_ExM2D7PV4S8PiR7hXNz X-Yahoo-Newman-Property: ymail-3 Message-ID: <4AF84071.5090606@netconfcentral.com> Date: Mon, 09 Nov 2009 08:16:49 -0800 From: Andy Bierman User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: Martin Bjorklund References: <20090430.160428.110485974.mbj@tail-f.com> <20091109.135245.24918919.mbj@tail-f.com> In-Reply-To: <20091109.135245.24918919.mbj@tail-f.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: netconf@ietf.org Subject: Re: [Netconf] 4741bis - multiple namespaces X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Nov 2009 16:16:09 -0000 Martin Bjorklund wrote: > Hi, > > http://trac.tools.ietf.org/wg/netconf/trac/wiki/Issues_4741bis#issue-006 > > This was discussed at the last IETF session (in Stockholm). The > consensus in the room was to remove the paragraph: > > > Martin Bjorklund wrote: >> Hi, >> >> Section 7.1 says: >> >> If the configuration is available in multiple formats, such as >> XML and text, an XML namespace can be used to specify which >> format is desired. In the following example, the client uses a >> specific element () in a specific namespace to >> indicate to the server the desire to receive the configuration in >> an alternative format. The server may support any number of >> distinct formats or views into the configuration data, with the >> client using the parameter to select between them. >> >> It looks like namespaces are used for two different purposes; >> different data models and different formats. This leads to some >> questions: >> >> Can the same be achieved with XPath? >> >> If no filter is specified, what should the server return - *all* >> namespaces (mulitple data models, multiple formats), or all >> namespaces for *some* format? How would you get all data for the >> text format? >> >> IMO this feature looks broken. >> >> >> Does anyone implement this? Can we remove this paragraph? > I think the text above is a bug. There is only 1 format -- XML. Each YANG module defines content in a different XML namespace. The text above is nonsense, and may confuse people into thinking YANG modules have different namespace URIs for different retrieval formats. > > Unless anyone objects, I will now remove it. > > > /martin Andy From andy@netconfcentral.com Mon Nov 9 08:36:49 2009 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2652B3A698D for ; Mon, 9 Nov 2009 08:36:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.088 X-Spam-Level: X-Spam-Status: No, score=-2.088 tagged_above=-999 required=5 tests=[AWL=0.176, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, UNPARSEABLE_RELAY=0.001] 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 iZ1-chlB5fcL for ; Mon, 9 Nov 2009 08:36:48 -0800 (PST) Received: from smtp128.sbc.mail.sp1.yahoo.com (smtp128.sbc.mail.sp1.yahoo.com [69.147.65.187]) by core3.amsl.com (Postfix) with SMTP id 781693A68BA for ; Mon, 9 Nov 2009 08:36:48 -0800 (PST) Received: (qmail 81436 invoked from network); 9 Nov 2009 16:37:12 -0000 Received: from adsl-67-125-158-26.dsl.irvnca.pacbell.net (andy@67.125.158.26 with plain) by smtp128.sbc.mail.sp1.yahoo.com with SMTP; 09 Nov 2009 08:37:12 -0800 PST X-Yahoo-SMTP: Z6xhxCCswBAlhcxjVNwaQtp4EKpLdTUUf5Nx_pGy81o- X-YMail-OSG: Too0PLEVM1mzG.uT4W.Vnu8S__HpougnDpq6zqPVexah2VezXxPdDc4Qt2sYG4HdOi..bxmosBXZraHdGttHZ1s9eA896cOpvLnM_7OImpKO04L8ur8YLXDjnqxej16sDPB8fVB2LVICQFnPDmIXkSzX7Q1CXr95kMFi7R7PRsbD9vgDtpacH4iAaRGi1ULcEO44MqlvGBqNwZ6yWfao7rznZNFJ29vyy1Ie0pgmUtkrKfZETvUdk0U03OZrsLZB X-Yahoo-Newman-Property: ymail-3 Message-ID: <4AF84547.70006@netconfcentral.com> Date: Mon, 09 Nov 2009 08:37:27 -0800 From: Andy Bierman User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: Phil Shafer References: <200911091538.nA9FcNHZ002893@idle.juniper.net> In-Reply-To: <200911091538.nA9FcNHZ002893@idle.juniper.net> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: netconf@ietf.org Subject: Re: [Netconf] warnings X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Nov 2009 16:36:49 -0000 Phil Shafer wrote: > Martin Bjorklund writes: >> Hmm.. this could probably be added in a backwards compatible way, but >> I'm not sure it is worth it. > > Warnings are meant to give information that the user or client > might need, but won't stop the device from doing as told. For > example, if you are installing a software image that requires > a reboot, a warning can announce this to the user. > > What NETCONF got wrong IMHO is that warnings are a classification > of errors, so attempting to give a warning is really giving an > error, which isn't acceptable. We had and as > distinct tags at one point, but collapsed the two ideas into a > meaningless mush. > > As it sits, warnings are unusable. Can we repair them? > I do not see how they can be repaired in a backward-compatible way. Existing clients see instead of and that is it. I doubt any clients check all the error-severity fields, see they are all warnings, and treat that as an . For example, introducing an element will break old clients talking to new servers. I prefer not to do that. The problem is that the protocol defines OR , but never both -- and clients rely on this fact. Also, the hard-wired list of error-tag values are defined to all have error-severity=error. I don't think the standard will ever use warnings. Even the use-case above is not a real warning. It is just part of the object behavior, as defined in the description-stmt. A warning is needed when something not defined in the YANG module happens during the server response. > Thanks, > Phil Andy From andy@netconfcentral.com Mon Nov 9 08:51:31 2009 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 86D033A69B2 for ; Mon, 9 Nov 2009 08:51:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[AWL=0.167, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, UNPARSEABLE_RELAY=0.001] 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 CAY0bkzkL0Bl for ; Mon, 9 Nov 2009 08:51:30 -0800 (PST) Received: from smtp128.sbc.mail.sp1.yahoo.com (smtp128.sbc.mail.sp1.yahoo.com [69.147.65.187]) by core3.amsl.com (Postfix) with SMTP id D35FE3A67B2 for ; Mon, 9 Nov 2009 08:51:30 -0800 (PST) Received: (qmail 950 invoked from network); 9 Nov 2009 16:51:57 -0000 Received: from adsl-67-125-158-26.dsl.irvnca.pacbell.net (andy@67.125.158.26 with plain) by smtp128.sbc.mail.sp1.yahoo.com with SMTP; 09 Nov 2009 08:51:57 -0800 PST X-Yahoo-SMTP: Z6xhxCCswBAlhcxjVNwaQtp4EKpLdTUUf5Nx_pGy81o- X-YMail-OSG: zcNThu0VM1n9RKIJNagbFXyGxef5_mAQTlCY0eIJOqN3wPIg2lZ7Et2A22m.xt1hitjrvmR3WzJ7IaEEAVb1nYFu3AR0.3KCMpjswKmrXIC0telHIC5Vduf6WbbQYc4MQDDfZ1VHp.cReHQ5UGhZ4T4bVwruet79HD8pz7vCAzNM.0dIMiWXhDnZLGwkuTE8eUpwaGgkRGmwX_i8X5SqvaSQbFNgZwVm2CxVBcjG4jZZJb1OZe7SK.lwMUboTtFu X-Yahoo-Newman-Property: ymail-3 Message-ID: <4AF848BC.1090706@netconfcentral.com> Date: Mon, 09 Nov 2009 08:52:12 -0800 From: Andy Bierman User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: Ladislav Lhotka References: <20091109.131325.241209342.mbj@tail-f.com> <1257775761.3555.67.camel@missotis> In-Reply-To: <1257775761.3555.67.camel@missotis> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Cc: netconf@ietf.org Subject: Re: [Netconf] 4741bis (011) - duplicate edit-config modifications X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Nov 2009 16:51:31 -0000 Ladislav Lhotka wrote: > Martin Bjorklund píše v Po 09. 11. 2009 v 13:13 +0100: >> Hi, >> >> This issue was brought up in the NETCONF session today. >> >> The problem is what happens in the following case, when mtu is a leaf: >> >> >> eth0 >> 100 >> 1500 >> >> >> The proposal was that the result is implementation specific, (just as >> in SNMP when the same variable occurs twice in a SET PDU). >> >> But Wes and Balazs argued that this a data model issue, and thus does >> not belong in 4741bis. For example, if mtu were a leaf-list, the XML >> above is perfectly fine. > > It was me, not Balazs. :-) I didn't agree with the formulation that the > result is implementation specific - every NETCONF implementation should > pass this data to the "Content Layer" because it is outside its scope. > > I don't know why this example is so specific - the same could be said > about an edit-config that uses unknown elements. It should suffice to > say that NETCONF doesn't care about data contents of the PDUs as long as > they satisfy some minimum requirements on well-formedness. > I think this needs to be left implementation-specific, just like SNMP. The PDU above may not be interpreted as a request to create 2 mtu leafs. It is more likely the server will see 2 separate attempts to merge a value into the mtu leaf. The only standard approach that makes sense to me is to declare the order to be significant, and last one wins. However, I prefer to leave this corner-case as an implementation-specific matter. The server needs to preserve order on 'ordered-by=user' lists/leaf-lists. We should not require any more than that. > Lada > >> I will close this issue for 4741bis, unless noone objects. >> >> >> /martin Andy From mbj@tail-f.com Mon Nov 9 10:03:05 2009 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E88B33A68F6 for ; Mon, 9 Nov 2009 10:03:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.997 X-Spam-Level: X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[AWL=0.049, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] 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 Jyq5n3KKWmEm for ; Mon, 9 Nov 2009 10:03:05 -0800 (PST) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id 23AF93A681E for ; Mon, 9 Nov 2009 10:03:05 -0800 (PST) Received: from localhost (c213-100-167-236.swipnet.se [213.100.167.236]) by mail.tail-f.com (Postfix) with ESMTPSA id 7E34F616004; Mon, 9 Nov 2009 19:03:29 +0100 (CET) Date: Mon, 09 Nov 2009 19:03:16 +0100 (CET) Message-Id: <20091109.190316.130234352.mbj@tail-f.com> To: andy@netconfcentral.com From: Martin Bjorklund In-Reply-To: <4AF84547.70006@netconfcentral.com> References: <200911091538.nA9FcNHZ002893@idle.juniper.net> <4AF84547.70006@netconfcentral.com> X-Mailer: Mew version 6.2.51 on Emacs 22.2 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: netconf@ietf.org Subject: Re: [Netconf] warnings X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Nov 2009 18:03:06 -0000 Andy Bierman wrote: > Phil Shafer wrote: > > Martin Bjorklund writes: > >> Hmm.. this could probably be added in a backwards compatible way, but > >> I'm not sure it is worth it. > > > > Warnings are meant to give information that the user or client > > might need, but won't stop the device from doing as told. For > > example, if you are installing a software image that requires > > a reboot, a warning can announce this to the user. > > > > What NETCONF got wrong IMHO is that warnings are a classification > > of errors, so attempting to give a warning is really giving an > > error, which isn't acceptable. We had and as > > distinct tags at one point, but collapsed the two ideas into a > > meaningless mush. > > > > As it sits, warnings are unusable. Can we repair them? > > > > I do not see how they can be repaired in a backward-compatible > way. I can see how we could introduce the kind of warnings that Lada mentioned (i.e. make it possible to continue an operation after a warning) but not the "info" warning that Phil wants. /martin From phil@juniper.net Mon Nov 9 10:20:24 2009 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4E5D03A6774 for ; Mon, 9 Nov 2009 10:20:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.551 X-Spam-Level: X-Spam-Status: No, score=-6.551 tagged_above=-999 required=5 tests=[AWL=0.048, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 75vt9eA0KzAm for ; Mon, 9 Nov 2009 10:20:23 -0800 (PST) Received: from exprod7og123.obsmtp.com (exprod7og123.obsmtp.com [64.18.2.24]) by core3.amsl.com (Postfix) with ESMTP id A8ABA3A6801 for ; Mon, 9 Nov 2009 10:20:22 -0800 (PST) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob123.postini.com ([64.18.6.12]) with SMTP ID DSNKSvhdfnMX3a/d3IvJiqMNxXM3IpxdtNlg@postini.com; Mon, 09 Nov 2009 10:20:50 PST Received: from p-emfe01-sac.jnpr.net (66.129.254.72) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server id 8.1.375.2; Mon, 9 Nov 2009 10:19:25 -0800 Received: from p-emlb02-sac.jnpr.net ([66.129.254.47]) by p-emfe01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Mon, 9 Nov 2009 10:19:25 -0800 Received: from emailsmtp55.jnpr.net ([172.24.18.132]) by p-emlb02-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Mon, 9 Nov 2009 10:19:25 -0800 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp55.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Mon, 9 Nov 2009 10:19:24 -0800 Received: from idle.juniper.net (idleski.juniper.net [172.25.4.26]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id nA9IJNj31071; Mon, 9 Nov 2009 10:19:24 -0800 (PST) (envelope-from phil@juniper.net) Received: from idle.juniper.net (localhost [127.0.0.1]) by idle.juniper.net (8.13.8/8.13.8) with ESMTP id nA9I69Xj004452; Mon, 9 Nov 2009 18:06:09 GMT (envelope-from phil@idle.juniper.net) Message-ID: <200911091806.nA9I69Xj004452@idle.juniper.net> To: Andy Bierman In-Reply-To: <4AF83F9D.70105@netconfcentral.com> Date: Mon, 9 Nov 2009 13:06:09 -0500 From: Phil Shafer X-OriginalArrivalTime: 09 Nov 2009 18:19:24.0809 (UTC) FILETIME=[2AA04F90:01CA6169] MIME-Version: 1.0 Content-Type: text/plain Cc: netconf@ietf.org Subject: Re: [Netconf] additional netconf (4741bis) issues X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Nov 2009 18:20:24 -0000 Andy Bierman writes: >There are NETCONF implementations that don't use YANG. >So what? There's no requirement in NETCONF that mandates the use of YANG. >IMO, this is a SHOULD requirement. We have already established >that the server knows all the default leafs, even when the >meta-data is incomplete so the client cannot deduce the values. We have also established (by existence proof) that NETCONF servers don't need W-D. It's a "nice to have", not something that is a requirement, SHOULD or otherwise. Thanks, Phil From phil@juniper.net Mon Nov 9 10:23:39 2009 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1D5553A6774 for ; Mon, 9 Nov 2009 10:23:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.552 X-Spam-Level: X-Spam-Status: No, score=-6.552 tagged_above=-999 required=5 tests=[AWL=0.047, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 Jh1NlsiRvSjM for ; Mon, 9 Nov 2009 10:23:38 -0800 (PST) Received: from exprod7og119.obsmtp.com (exprod7og119.obsmtp.com [64.18.2.16]) by core3.amsl.com (Postfix) with ESMTP id 4EB5E3A6403 for ; Mon, 9 Nov 2009 10:23:37 -0800 (PST) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob119.postini.com ([64.18.6.12]) with SMTP ID DSNKSvheQZhqP9l3GIm8pi40RGG+Z2r5/oRf@postini.com; Mon, 09 Nov 2009 10:24:05 PST Received: from p-emfe01-sac.jnpr.net (66.129.254.72) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server id 8.1.375.2; Mon, 9 Nov 2009 10:23:07 -0800 Received: from p-emlb01-sac.jnpr.net ([66.129.254.46]) by p-emfe01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Mon, 9 Nov 2009 10:23:07 -0800 Received: from emailsmtp55.jnpr.net ([172.24.18.132]) by p-emlb01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Mon, 9 Nov 2009 10:23:06 -0800 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp55.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Mon, 9 Nov 2009 10:23:06 -0800 Received: from idle.juniper.net (idleski.juniper.net [172.25.4.26]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id nA9IN5j32756; Mon, 9 Nov 2009 10:23:05 -0800 (PST) (envelope-from phil@juniper.net) Received: from idle.juniper.net (localhost [127.0.0.1]) by idle.juniper.net (8.13.8/8.13.8) with ESMTP id nA9I9o6r004526; Mon, 9 Nov 2009 18:09:51 GMT (envelope-from phil@idle.juniper.net) Message-ID: <200911091809.nA9I9o6r004526@idle.juniper.net> To: Andy Bierman In-Reply-To: <4AF84547.70006@netconfcentral.com> Date: Mon, 9 Nov 2009 13:09:50 -0500 From: Phil Shafer X-OriginalArrivalTime: 09 Nov 2009 18:23:06.0198 (UTC) FILETIME=[AE959760:01CA6169] MIME-Version: 1.0 Content-Type: text/plain Cc: netconf@ietf.org Subject: Re: [Netconf] warnings X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Nov 2009 18:23:39 -0000 Andy Bierman writes: >The problem is that the protocol defines OR , >but never both -- and clients rely on this fact. Add that can exist with . >I don't think the standard will ever use warnings. >Even the use-case above is not a real warning. It is just >part of the object behavior, as defined in the description-stmt. >A warning is needed when something not defined in the YANG module >happens during the server response. Such as "you asked me to do something and I did but here's something you should know" (like "you need to reboot now"). Thanks, Phil From phil@juniper.net Mon Nov 9 10:27:15 2009 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 044443A6912 for ; Mon, 9 Nov 2009 10:27:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.552 X-Spam-Level: X-Spam-Status: No, score=-6.552 tagged_above=-999 required=5 tests=[AWL=0.047, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 GuU0NXUaKNFI for ; Mon, 9 Nov 2009 10:27:14 -0800 (PST) Received: from exprod7og104.obsmtp.com (exprod7og104.obsmtp.com [64.18.2.161]) by core3.amsl.com (Postfix) with ESMTP id 0E48B3A6852 for ; Mon, 9 Nov 2009 10:27:13 -0800 (PST) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob104.postini.com ([64.18.6.12]) with SMTP ID DSNKSvhfGjZIjz23wg9qVVeQ2BZtgLKyzS9V@postini.com; Mon, 09 Nov 2009 10:27:40 PST Received: from p-emfe01-sac.jnpr.net (66.129.254.72) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server id 8.1.375.2; Mon, 9 Nov 2009 10:27:14 -0800 Received: from p-emlb01-sac.jnpr.net ([66.129.254.46]) by p-emfe01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Mon, 9 Nov 2009 10:27:14 -0800 Received: from emailsmtp55.jnpr.net ([172.24.18.132]) by p-emlb01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Mon, 9 Nov 2009 10:27:14 -0800 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp55.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Mon, 9 Nov 2009 10:27:14 -0800 Received: from idle.juniper.net (idleski.juniper.net [172.25.4.26]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id nA9IRDj35191; Mon, 9 Nov 2009 10:27:13 -0800 (PST) (envelope-from phil@juniper.net) Received: from idle.juniper.net (localhost [127.0.0.1]) by idle.juniper.net (8.13.8/8.13.8) with ESMTP id nA9IDw0w004624; Mon, 9 Nov 2009 18:13:59 GMT (envelope-from phil@idle.juniper.net) Message-ID: <200911091813.nA9IDw0w004624@idle.juniper.net> To: Martin Bjorklund In-Reply-To: <20091109.171537.197959890.mbj@tail-f.com> Date: Mon, 9 Nov 2009 13:13:58 -0500 From: Phil Shafer X-OriginalArrivalTime: 09 Nov 2009 18:27:14.0056 (UTC) FILETIME=[4251B880:01CA616A] MIME-Version: 1.0 Content-Type: text/plain Cc: netconf@ietf.org Subject: Re: [Netconf] 4741bis - multiple namespaces X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Nov 2009 18:27:15 -0000 Martin Bjorklund writes: >Hmm... what does this have to do with the paragraph about multiple >formats? What you ask for is covered by the text on subtree >filtering. Same mechanism, being able to fetch based on namespace, not element name. >The paragraph also talks about different views of the data. This is >an interesting topic. For example, I think we want to support the >case that a device implements a native data model (acme-foo.yang), and >a standard model (ietf-foo.yang). The standard model might be just a >transform into - or different view of - the native data model. [I >realize that this has been discussed before on the ML...]. Now, when >you do a w/o any filters, what do you get? For JUNOS, you'll get the native stuff. If you want ietf-foo, you'll need to provide the namespace for that module as your filter. I'll use that namespace to trigger my translation into that data model.. Thanks, Phil From andy@netconfcentral.com Mon Nov 9 11:28:46 2009 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 418C73A6B9E for ; Mon, 9 Nov 2009 11:28:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.134 X-Spam-Level: X-Spam-Status: No, score=-2.134 tagged_above=-999 required=5 tests=[AWL=0.464, BAYES_00=-2.599, UNPARSEABLE_RELAY=0.001] 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 d0KAEyX+b-RA for ; Mon, 9 Nov 2009 11:28:45 -0800 (PST) Received: from smtp107.sbc.mail.mud.yahoo.com (smtp107.sbc.mail.mud.yahoo.com [68.142.198.105]) by core3.amsl.com (Postfix) with SMTP id 6996A3A6B9C for ; Mon, 9 Nov 2009 11:28:45 -0800 (PST) Received: (qmail 57438 invoked from network); 9 Nov 2009 19:29:09 -0000 Received: from adsl-67-125-158-26.dsl.irvnca.pacbell.net (andy@67.125.158.26 with plain) by smtp107.sbc.mail.mud.yahoo.com with SMTP; 09 Nov 2009 11:29:09 -0800 PST X-Yahoo-SMTP: Z6xhxCCswBAlhcxjVNwaQtp4EKpLdTUUf5Nx_pGy81o- X-YMail-OSG: vEAhN54VM1ksGjcVI.vqzDJpCJlAazaKg0tqbon0XqyG0W5bh0V81RdhaGsvQG3ZJNzElTu59eF_5eQCnRJ0HnDIa5nMVDhNxtemy51kvUG091kzX.evtsj6FpJxklXpBMl8fDwfmCPx4opQ4EPNX4Jf8y48aVNJCel9mzGJ0O.8NuYhGqOFVMvdikT6v4rsDhd4dt9Du5PdGrS3zC7LQFFkniGlWqhxS6Sxa81uF16XI3WHisgum2Vv_HqTzRrzJ1heiCq27vbBqiMuWqBJQDnr.RgncZuJHkbrSY5Mujz8n3RsPDZQtArcgCbyb1rqQfmRv5F_RxYqRDbZd_bkfrWVECFw3cYIBEZhZW2tnwWwVv9EKuPHj5e5OZk- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4AF86D95.4000006@netconfcentral.com> Date: Mon, 09 Nov 2009 11:29:25 -0800 From: Andy Bierman User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: Phil Shafer References: <200911091813.nA9IDw0w004624@idle.juniper.net> In-Reply-To: <200911091813.nA9IDw0w004624@idle.juniper.net> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: netconf@ietf.org Subject: Re: [Netconf] 4741bis - multiple namespaces X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Nov 2009 19:28:46 -0000 Phil Shafer wrote: > Martin Bjorklund writes: >> Hmm... what does this have to do with the paragraph about multiple >> formats? What you ask for is covered by the text on subtree >> filtering. > > Same mechanism, being able to fetch based on namespace, not element > name. But subtree filtering has no way to specify 'any element in this namespace'. The charter says we are keeping backward compatibility with RFC 4741 implementations. Since this is already supported in XPath, it is not really needed in subtree filtering. I prefer to finish 4741bis ASAP, and stop adding new features. > >> The paragraph also talks about different views of the data. This is >> an interesting topic. For example, I think we want to support the >> case that a device implements a native data model (acme-foo.yang), and >> a standard model (ietf-foo.yang). The standard model might be just a >> transform into - or different view of - the native data model. [I >> realize that this has been discussed before on the ML...]. Now, when >> you do a w/o any filters, what do you get? > > For JUNOS, you'll get the native stuff. If you want ietf-foo, you'll > need to provide the namespace for that module as your filter. I'll > use that namespace to trigger my translation into that data model.. > > Thanks, > Phil Andy From lhotka@cesnet.cz Mon Nov 9 15:30:45 2009 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7F9F83A6819 for ; Mon, 9 Nov 2009 15:30:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.25 X-Spam-Level: X-Spam-Status: No, score=-1.25 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904] 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 LDr17uWCA12P for ; Mon, 9 Nov 2009 15:30:44 -0800 (PST) Received: from office2.cesnet.cz (office2.cesnet.cz [195.113.144.244]) by core3.amsl.com (Postfix) with ESMTP id 8FB703A6808 for ; Mon, 9 Nov 2009 15:30:44 -0800 (PST) Received: from [133.93.113.127] (host-113-127.meeting.ietf.org [133.93.113.127]) by office2.cesnet.cz (Postfix) with ESMTP id AA482D800F3; Tue, 10 Nov 2009 00:31:04 +0100 (CET) From: Ladislav Lhotka To: Martin Bjorklund In-Reply-To: <20091109.164151.152756359.mbj@tail-f.com> References: <20091109.145239.111899012.mbj@tail-f.com> <1257780863.3555.131.camel@missotis> <20091109.164151.152756359.mbj@tail-f.com> Content-Type: text/plain; charset="UTF-8" Organization: CESNET Date: Tue, 10 Nov 2009 08:30:57 +0900 Message-Id: <1257809457.3467.14.camel@missotis> Mime-Version: 1.0 X-Mailer: Evolution 2.26.1 Content-Transfer-Encoding: 8bit Cc: netconf@ietf.org Subject: Re: [Netconf] 4741bis (007) - return from XPath filters X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Nov 2009 23:30:45 -0000 Martin Bjorklund píše v Po 09. 11. 2009 v 16:41 +0100: > Ladislav Lhotka wrote: > > Martin Bjorklund píše v Po 09. 11. 2009 v 14:52 +0100: > > > I suggest we add this to 8.9.1: > > > > > > The response message contains the subtrees selected by the filter > > > expression. For each such subtree, the path from the data model > > > root node down to the subtree, including any elements or > > > attributes necessary to uniquely identify the subtree, are > > > included in the response message. > > > > Hmm, how do you recognize such elements or attributes? NETCONF has no > > notion of list keys, so there may be multiple ways how to satisfy this > > requirement. For instance, in a user database both uid and username will > > be unique although only one of them will be used as the list key in > > YANG. > > Sure, that will be data model dependent. Is that a problem? Let's say we have a YANG data model that has "uid" as the only key. Still, the return value for the XPath query may use either "uid" or "username", both satisfying the above requirement. Even "fullname" could do, if this item happens to be unique in a particular instance, right? You really want to say "list keys" here. Lada > > > /martin -- Ladislav Lhotka, CESNET PGP Key ID: E74E8C0C From mbj@tail-f.com Mon Nov 9 15:34:50 2009 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C39ED28C266 for ; Mon, 9 Nov 2009 15:34:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.986 X-Spam-Level: X-Spam-Status: No, score=-1.986 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] 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 AskLJt0kBeFf for ; Mon, 9 Nov 2009 15:34:50 -0800 (PST) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id D26F93A6819 for ; Mon, 9 Nov 2009 15:34:48 -0800 (PST) Received: from localhost (c213-100-167-236.swipnet.se [213.100.167.236]) by mail.tail-f.com (Postfix) with ESMTPSA id 36548616001; Tue, 10 Nov 2009 00:35:15 +0100 (CET) Date: Tue, 10 Nov 2009 00:35:14 +0100 (CET) Message-Id: <20091110.003514.81111448.mbj@tail-f.com> To: lhotka@cesnet.cz From: Martin Bjorklund In-Reply-To: <1257809457.3467.14.camel@missotis> References: <1257780863.3555.131.camel@missotis> <20091109.164151.152756359.mbj@tail-f.com> <1257809457.3467.14.camel@missotis> X-Mailer: Mew version 6.2.51 on Emacs 22.2 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=utf-8 Content-Transfer-Encoding: base64 Cc: netconf@ietf.org Subject: Re: [Netconf] 4741bis (007) - return from XPath filters X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Nov 2009 23:34:50 -0000 TGFkaXNsYXYgTGhvdGthIDxsaG90a2FAY2VzbmV0LmN6PiB3cm90ZToNCj4gTWFydGluIEJqb3Jr bHVuZCBww63FoWUgdiBQbyAwOS4gMTEuIDIwMDkgdiAxNjo0MSArMDEwMDoNCj4gPiBMYWRpc2xh diBMaG90a2EgPGxob3RrYUBjZXNuZXQuY3o+IHdyb3RlOg0KPiA+ID4gTWFydGluIEJqb3JrbHVu ZCBww63FoWUgdiBQbyAwOS4gMTEuIDIwMDkgdiAxNDo1MiArMDEwMDoNCj4gPiA+ID4gSSBzdWdn ZXN0IHdlIGFkZCB0aGlzIHRvIDguOS4xOg0KPiA+ID4gPiANCj4gPiA+ID4gICAgIFRoZSByZXNw b25zZSBtZXNzYWdlIGNvbnRhaW5zIHRoZSBzdWJ0cmVlcyBzZWxlY3RlZCBieSB0aGUgZmlsdGVy DQo+ID4gPiA+ICAgICBleHByZXNzaW9uLiAgRm9yIGVhY2ggc3VjaCBzdWJ0cmVlLCB0aGUgcGF0 aCBmcm9tIHRoZSBkYXRhIG1vZGVsDQo+ID4gPiA+ICAgICByb290IG5vZGUgZG93biB0byB0aGUg c3VidHJlZSwgaW5jbHVkaW5nIGFueSBlbGVtZW50cyBvcg0KPiA+ID4gPiAgICAgYXR0cmlidXRl cyBuZWNlc3NhcnkgdG8gdW5pcXVlbHkgaWRlbnRpZnkgdGhlIHN1YnRyZWUsIGFyZQ0KPiA+ID4g PiAgICAgaW5jbHVkZWQgaW4gdGhlIHJlc3BvbnNlIG1lc3NhZ2UuDQo+ID4gPiANCj4gPiA+IEht bSwgaG93IGRvIHlvdSByZWNvZ25pemUgc3VjaCBlbGVtZW50cyBvciBhdHRyaWJ1dGVzPyBORVRD T05GIGhhcyBubw0KPiA+ID4gbm90aW9uIG9mIGxpc3Qga2V5cywgc28gdGhlcmUgbWF5IGJlIG11 bHRpcGxlIHdheXMgaG93IHRvIHNhdGlzZnkgdGhpcw0KPiA+ID4gcmVxdWlyZW1lbnQuIEZvciBp bnN0YW5jZSwgaW4gYSB1c2VyIGRhdGFiYXNlIGJvdGggdWlkIGFuZCB1c2VybmFtZSB3aWxsDQo+ ID4gPiBiZSB1bmlxdWUgYWx0aG91Z2ggb25seSBvbmUgb2YgdGhlbSB3aWxsIGJlIHVzZWQgYXMg dGhlIGxpc3Qga2V5IGluDQo+ID4gPiBZQU5HLg0KPiA+IA0KPiA+IFN1cmUsIHRoYXQgd2lsbCBi ZSBkYXRhIG1vZGVsIGRlcGVuZGVudC4gIElzIHRoYXQgYSBwcm9ibGVtPw0KPiANCj4gTGV0J3Mg c2F5IHdlIGhhdmUgYSBZQU5HIGRhdGEgbW9kZWwgdGhhdCBoYXMgInVpZCIgYXMgdGhlIG9ubHkg a2V5Lg0KPiBTdGlsbCwgdGhlIHJldHVybiB2YWx1ZSBmb3IgdGhlIFhQYXRoIHF1ZXJ5IG1heSB1 c2UgZWl0aGVyICJ1aWQiIG9yDQo+ICJ1c2VybmFtZSIsIGJvdGggc2F0aXNmeWluZyB0aGUgYWJv dmUgcmVxdWlyZW1lbnQuIEV2ZW4gImZ1bGxuYW1lIiBjb3VsZA0KPiBkbywgaWYgdGhpcyBpdGVt IGhhcHBlbnMgdG8gYmUgdW5pcXVlIGluIGEgcGFydGljdWxhciBpbnN0YW5jZSwgcmlnaHQ/DQoN Ck9yIG1heWJlIHRoZXJlIGlzIGp1c3Qgb25lIHVzZXIgd2l0aCBsZW5ndGggMjAyIGNtLCBzbyB0 aGF0IHdvdWxkIGJlDQp1bmlxdWU/DQoNCldoYXQgc29ydCBvZiB0ZXh0IGRvIHdlIG5lZWQgdG8g bWFrZSB0aGUgaW50ZW50aW9uIGNsZWFyPw0KDQoNCj4gWW91IHJlYWxseSB3YW50IHRvIHNheSAi bGlzdCBrZXlzIiBoZXJlLg0KDQpObywgYi9jIHRoYXQgaXMgWUFORyBzcGVjaWZpYy4NCg0KDQov bWFydGluDQo= From mbj@tail-f.com Mon Nov 9 15:48:32 2009 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 420823A68C5 for ; Mon, 9 Nov 2009 15:48:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.983 X-Spam-Level: X-Spam-Status: No, score=-1.983 tagged_above=-999 required=5 tests=[AWL=0.063, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] 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 PfiUEeV7xt7b for ; Mon, 9 Nov 2009 15:48:31 -0800 (PST) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id 736773A67B6 for ; Mon, 9 Nov 2009 15:48:31 -0800 (PST) Received: from localhost (c213-100-167-236.swipnet.se [213.100.167.236]) by mail.tail-f.com (Postfix) with ESMTPSA id AB026616001; Tue, 10 Nov 2009 00:48:57 +0100 (CET) Date: Tue, 10 Nov 2009 00:48:57 +0100 (CET) Message-Id: <20091110.004857.195549072.mbj@tail-f.com> To: phil@juniper.net From: Martin Bjorklund In-Reply-To: <200911091809.nA9I9o6r004526@idle.juniper.net> References: <4AF84547.70006@netconfcentral.com> <200911091809.nA9I9o6r004526@idle.juniper.net> X-Mailer: Mew version 6.2.51 on Emacs 22.2 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: netconf@ietf.org Subject: Re: [Netconf] warnings X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Nov 2009 23:48:32 -0000 Phil Shafer wrote: > Andy Bierman writes: > >The problem is that the protocol defines OR , > >but never both -- and clients rely on this fact. > > Add that can exist with . But that would be an incompatible change, i.e. it might break existing clients. I don't think we should do that in this case. /martin From lhotka@cesnet.cz Mon Nov 9 17:42:30 2009 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A34E928C197 for ; Mon, 9 Nov 2009 17:42:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.25 X-Spam-Level: X-Spam-Status: No, score=-1.25 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904] 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 gZ12af07DBVp for ; Mon, 9 Nov 2009 17:42:29 -0800 (PST) Received: from office2.cesnet.cz (office2.cesnet.cz [195.113.144.244]) by core3.amsl.com (Postfix) with ESMTP id 8E0733A68E0 for ; Mon, 9 Nov 2009 17:42:29 -0800 (PST) Received: from [133.93.19.175] (host-19-175.meeting.ietf.org [133.93.19.175]) by office2.cesnet.cz (Postfix) with ESMTP id F1291D800E8; Tue, 10 Nov 2009 02:42:53 +0100 (CET) From: Ladislav Lhotka To: Martin Bjorklund In-Reply-To: <20091110.003514.81111448.mbj@tail-f.com> References: <1257780863.3555.131.camel@missotis> <20091109.164151.152756359.mbj@tail-f.com> <1257809457.3467.14.camel@missotis> <20091110.003514.81111448.mbj@tail-f.com> Content-Type: text/plain; charset="UTF-8" Organization: CESNET Date: Tue, 10 Nov 2009 10:42:49 +0900 Message-Id: <1257817369.7700.22.camel@missotis> Mime-Version: 1.0 X-Mailer: Evolution 2.26.1 Content-Transfer-Encoding: 8bit Cc: netconf@ietf.org Subject: Re: [Netconf] 4741bis (007) - return from XPath filters X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Nov 2009 01:42:30 -0000 Martin Bjorklund píše v Út 10. 11. 2009 v 00:35 +0100: > Ladislav Lhotka wrote: > > Martin Bjorklund píše v Po 09. 11. 2009 v 16:41 +0100: > > > Ladislav Lhotka wrote: > > > > Martin Bjorklund píše v Po 09. 11. 2009 v 14:52 +0100: > > > > > I suggest we add this to 8.9.1: > > > > > > > > > > The response message contains the subtrees selected by the filter > > > > > expression. For each such subtree, the path from the data model > > > > > root node down to the subtree, including any elements or > > > > > attributes necessary to uniquely identify the subtree, are > > > > > included in the response message. > > > > > > > > Hmm, how do you recognize such elements or attributes? NETCONF has no > > > > notion of list keys, so there may be multiple ways how to satisfy this > > > > requirement. For instance, in a user database both uid and username will > > > > be unique although only one of them will be used as the list key in > > > > YANG. > > > > > > Sure, that will be data model dependent. Is that a problem? > > > > Let's say we have a YANG data model that has "uid" as the only key. > > Still, the return value for the XPath query may use either "uid" or > > "username", both satisfying the above requirement. Even "fullname" could > > do, if this item happens to be unique in a particular instance, right? > > Or maybe there is just one user with length 202 cm, so that would be > unique? Yes, or if there is only one subtree, you don't need anything to identify it. > > What sort of text do we need to make the intention clear? > I think the cleanest solution would be to just define the "schema" for RPC requests utilizing the XPath capability and leave the spec of XPath query sematics to YANG (or other DM languages, for that matter). YANG already fills some gaps in the semantics of NETCONF operations (e.g., edit-config for lists in Sec. 7.8.6), so it wouldn't be a really new situation. > > > You really want to say "list keys" here. > > No, b/c that is YANG specific. > Indeed, because it is specific to the Content layer, so NETCONF spec shouldn't address it at all. Lada > > /martin -- Ladislav Lhotka, CESNET PGP Key ID: E74E8C0C From mbj@tail-f.com Mon Nov 9 23:47:48 2009 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 215C83A67DD for ; Mon, 9 Nov 2009 23:47:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.984 X-Spam-Level: X-Spam-Status: No, score=-1.984 tagged_above=-999 required=5 tests=[AWL=0.062, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] 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 RYKpF6LWCv70 for ; Mon, 9 Nov 2009 23:47:47 -0800 (PST) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id 074733A692F for ; Mon, 9 Nov 2009 23:47:46 -0800 (PST) Received: from localhost (c213-100-167-236.swipnet.se [213.100.167.236]) by mail.tail-f.com (Postfix) with ESMTPSA id 7E8AE616002; Tue, 10 Nov 2009 08:48:12 +0100 (CET) Date: Tue, 10 Nov 2009 08:48:12 +0100 (CET) Message-Id: <20091110.084812.181661537.mbj@tail-f.com> To: lhotka@cesnet.cz From: Martin Bjorklund In-Reply-To: <1257817369.7700.22.camel@missotis> References: <1257809457.3467.14.camel@missotis> <20091110.003514.81111448.mbj@tail-f.com> <1257817369.7700.22.camel@missotis> X-Mailer: Mew version 6.2.51 on Emacs 22.2 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=utf-8 Content-Transfer-Encoding: base64 Cc: netconf@ietf.org Subject: Re: [Netconf] 4741bis (007) - return from XPath filters X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Nov 2009 07:47:48 -0000 TGFkaXNsYXYgTGhvdGthIDxsaG90a2FAY2VzbmV0LmN6PiB3cm90ZToNCj4gTWFydGluIEJqb3Jr bHVuZCBww63FoWUgdiDDmnQgMTAuIDExLiAyMDA5IHYgMDA6MzUgKzAxMDA6DQo+ID4gTGFkaXNs YXYgTGhvdGthIDxsaG90a2FAY2VzbmV0LmN6PiB3cm90ZToNCj4gPiA+IE1hcnRpbiBCam9ya2x1 bmQgcMOtxaFlIHYgUG8gMDkuIDExLiAyMDA5IHYgMTY6NDEgKzAxMDA6DQo+ID4gPiA+IExhZGlz bGF2IExob3RrYSA8bGhvdGthQGNlc25ldC5jej4gd3JvdGU6DQo+ID4gPiA+ID4gTWFydGluIEJq b3JrbHVuZCBww63FoWUgdiBQbyAwOS4gMTEuIDIwMDkgdiAxNDo1MiArMDEwMDoNCj4gPiA+ID4g PiA+IEkgc3VnZ2VzdCB3ZSBhZGQgdGhpcyB0byA4LjkuMToNCj4gPiA+ID4gPiA+IA0KPiA+ID4g PiA+ID4gICAgIFRoZSByZXNwb25zZSBtZXNzYWdlIGNvbnRhaW5zIHRoZSBzdWJ0cmVlcyBzZWxl Y3RlZCBieSB0aGUgZmlsdGVyDQo+ID4gPiA+ID4gPiAgICAgZXhwcmVzc2lvbi4gIEZvciBlYWNo IHN1Y2ggc3VidHJlZSwgdGhlIHBhdGggZnJvbSB0aGUgZGF0YSBtb2RlbA0KPiA+ID4gPiA+ID4g ICAgIHJvb3Qgbm9kZSBkb3duIHRvIHRoZSBzdWJ0cmVlLCBpbmNsdWRpbmcgYW55IGVsZW1lbnRz IG9yDQo+ID4gPiA+ID4gPiAgICAgYXR0cmlidXRlcyBuZWNlc3NhcnkgdG8gdW5pcXVlbHkgaWRl bnRpZnkgdGhlIHN1YnRyZWUsIGFyZQ0KPiA+ID4gPiA+ID4gICAgIGluY2x1ZGVkIGluIHRoZSBy ZXNwb25zZSBtZXNzYWdlLg0KPiA+ID4gPiA+IA0KPiA+ID4gPiA+IEhtbSwgaG93IGRvIHlvdSBy ZWNvZ25pemUgc3VjaCBlbGVtZW50cyBvciBhdHRyaWJ1dGVzPyBORVRDT05GIGhhcyBubw0KPiA+ ID4gPiA+IG5vdGlvbiBvZiBsaXN0IGtleXMsIHNvIHRoZXJlIG1heSBiZSBtdWx0aXBsZSB3YXlz IGhvdyB0byBzYXRpc2Z5IHRoaXMNCj4gPiA+ID4gPiByZXF1aXJlbWVudC4gRm9yIGluc3RhbmNl LCBpbiBhIHVzZXIgZGF0YWJhc2UgYm90aCB1aWQgYW5kIHVzZXJuYW1lIHdpbGwNCj4gPiA+ID4g PiBiZSB1bmlxdWUgYWx0aG91Z2ggb25seSBvbmUgb2YgdGhlbSB3aWxsIGJlIHVzZWQgYXMgdGhl IGxpc3Qga2V5IGluDQo+ID4gPiA+ID4gWUFORy4NCj4gPiA+ID4gDQo+ID4gPiA+IFN1cmUsIHRo YXQgd2lsbCBiZSBkYXRhIG1vZGVsIGRlcGVuZGVudC4gIElzIHRoYXQgYSBwcm9ibGVtPw0KPiA+ ID4gDQo+ID4gPiBMZXQncyBzYXkgd2UgaGF2ZSBhIFlBTkcgZGF0YSBtb2RlbCB0aGF0IGhhcyAi dWlkIiBhcyB0aGUgb25seSBrZXkuDQo+ID4gPiBTdGlsbCwgdGhlIHJldHVybiB2YWx1ZSBmb3Ig dGhlIFhQYXRoIHF1ZXJ5IG1heSB1c2UgZWl0aGVyICJ1aWQiIG9yDQo+ID4gPiAidXNlcm5hbWUi LCBib3RoIHNhdGlzZnlpbmcgdGhlIGFib3ZlIHJlcXVpcmVtZW50LiBFdmVuICJmdWxsbmFtZSIg Y291bGQNCj4gPiA+IGRvLCBpZiB0aGlzIGl0ZW0gaGFwcGVucyB0byBiZSB1bmlxdWUgaW4gYSBw YXJ0aWN1bGFyIGluc3RhbmNlLCByaWdodD8NCj4gPiANCj4gPiBPciBtYXliZSB0aGVyZSBpcyBq dXN0IG9uZSB1c2VyIHdpdGggbGVuZ3RoIDIwMiBjbSwgc28gdGhhdCB3b3VsZCBiZQ0KPiA+IHVu aXF1ZT8NCj4gDQo+IFllcywgb3IgaWYgdGhlcmUgaXMgb25seSBvbmUgc3VidHJlZSwgeW91IGRv bid0IG5lZWQgYW55dGhpbmcgdG8NCj4gaWRlbnRpZnkgaXQuDQo+IA0KPiA+IA0KPiA+IFdoYXQg c29ydCBvZiB0ZXh0IGRvIHdlIG5lZWQgdG8gbWFrZSB0aGUgaW50ZW50aW9uIGNsZWFyPw0KPiA+ IA0KPiANCj4gSSB0aGluayB0aGUgY2xlYW5lc3Qgc29sdXRpb24gd291bGQgYmUgdG8ganVzdCBk ZWZpbmUgdGhlICJzY2hlbWEiIGZvcg0KPiBSUEMgcmVxdWVzdHMgdXRpbGl6aW5nIHRoZSBYUGF0 aCBjYXBhYmlsaXR5IGFuZCBsZWF2ZSB0aGUgc3BlYyBvZiBYUGF0aA0KPiBxdWVyeSBzZW1hdGlj cyB0byBZQU5HIChvciBvdGhlciBETSBsYW5ndWFnZXMsIGZvciB0aGF0IG1hdHRlcikuDQoNCkkg dGhpbmsgd2UgY2FuIGFuZCBzaG91bGQgZG8gYmV0dGVyLiAgUmVnYXJkbGVzcyBvZiBETSBsYW5n dWFnZSwgd2UNCndhbnQgdGhlIFhQYXRoIGZpbHRlciB0byByZXR1cm4gWE1MICJhcyBmb3Igc3Vi dHJlZSBmaWx0ZXJzIiwgcmlnaHQ/DQoNCkhvdyBhYm91dCB0aGlzOg0KDQogICAgVGhlIHJlc3Bv bnNlIG1lc3NhZ2UgY29udGFpbnMgdGhlIHN1YnRyZWVzIHNlbGVjdGVkIGJ5IHRoZSBmaWx0ZXIN CiAgICBleHByZXNzaW9uLiAgRm9yIGVhY2ggc3VjaCBzdWJ0cmVlLCB0aGUgcGF0aCBmcm9tIHRo ZSBkYXRhIG1vZGVsDQogICAgcm9vdCBub2RlIGRvd24gdG8gdGhlIHN1YnRyZWUsIGluY2x1ZGlu ZyBhbnkgZWxlbWVudHMgb3IgYXR0cmlidXRlcw0KICAgIG5lY2Vzc2FyeSwgYXMgZGVmaW5lZCBi eSB0aGUgZGF0YSBtb2RlbCwgdG8gdW5pcXVlbHkgaWRlbnRpZnkgdGhlDQogICAgc3VidHJlZSwg YXJlIGluY2x1ZGVkIGluIHRoZSByZXNwb25zZSBtZXNzYWdlLg0KDQoNCi9tYXJ0aW4NCg== From lhotka@cesnet.cz Tue Nov 10 06:21:30 2009 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EE7A43A6AD4 for ; Tue, 10 Nov 2009 06:21:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.25 X-Spam-Level: X-Spam-Status: No, score=-1.25 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904] 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 N-j0T8DZfnTK for ; Tue, 10 Nov 2009 06:21:30 -0800 (PST) Received: from office2.cesnet.cz (office2.cesnet.cz [195.113.144.244]) by core3.amsl.com (Postfix) with ESMTP id F06DD3A6AC6 for ; Tue, 10 Nov 2009 06:21:29 -0800 (PST) Received: from [133.93.113.127] (host-113-127.meeting.ietf.org [133.93.113.127]) by office2.cesnet.cz (Postfix) with ESMTP id 92337D800F4; Tue, 10 Nov 2009 15:21:55 +0100 (CET) From: Ladislav Lhotka To: Martin Bjorklund In-Reply-To: <20091110.084812.181661537.mbj@tail-f.com> References: <1257809457.3467.14.camel@missotis> <20091110.003514.81111448.mbj@tail-f.com> <1257817369.7700.22.camel@missotis> <20091110.084812.181661537.mbj@tail-f.com> Content-Type: text/plain; charset="UTF-8" Organization: CESNET Date: Tue, 10 Nov 2009 23:21:50 +0900 Message-Id: <1257862910.25407.53.camel@missotis> Mime-Version: 1.0 X-Mailer: Evolution 2.26.1 Content-Transfer-Encoding: 8bit Cc: netconf@ietf.org Subject: Re: [Netconf] 4741bis (007) - return from XPath filters X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Nov 2009 14:21:31 -0000 Martin Bjorklund píše v Út 10. 11. 2009 v 08:48 +0100: > > I think the cleanest solution would be to just define the "schema" for > > RPC requests utilizing the XPath capability and leave the spec of XPath > > query sematics to YANG (or other DM languages, for that matter). > > I think we can and should do better. Regardless of DM language, we > want the XPath filter to return XML "as for subtree filters", right? Is the subtree filtering mechanism supposed to fill-in all "list keys" in the ancestor hierarchy? Where is this said? > > How about this: > > The response message contains the subtrees selected by the filter > expression. For each such subtree, the path from the data model > root node down to the subtree, including any elements or attributes > necessary, as defined by the data model, to uniquely identify the > subtree, are included in the response message. > It would be so easy to express this in YANG terms. :-) I don't know: If you want to determine whether a given reply satisfies this requirement, you have to look-up the DML spec to find out what these identifying elements/attributes are. You cannot tell this just by looking to the XML. I think it is pretty much the same problem as deciding about the duplicate leaf in edit-config, which we classified as not being NETCONF protocol issue. Anyway, what is it really supposed to mean? If I have module foo { namespace "http://example.org/foo"; prefix foo; container top { list outer { key outer-key; leaf outer-key { ... } list inner { key inner-key; leaf inner-key { ... } leaf bar { ... } } } } } and then use XPath selector "/foo:top/foo:outer/foo:inner/foo:bar", will the returned output contain both outer-keys and inner-keys? Lada > > /martin -- Ladislav Lhotka, CESNET PGP Key ID: E74E8C0C From mbj@tail-f.com Tue Nov 10 06:30:32 2009 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C3D2A3A6ADF for ; Tue, 10 Nov 2009 06:30:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.988 X-Spam-Level: X-Spam-Status: No, score=-1.988 tagged_above=-999 required=5 tests=[AWL=0.058, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] 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 axJFSgvvfWnJ for ; Tue, 10 Nov 2009 06:30:32 -0800 (PST) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id D6C623A6AE4 for ; Tue, 10 Nov 2009 06:30:31 -0800 (PST) Received: from localhost (c213-100-167-236.swipnet.se [213.100.167.236]) by mail.tail-f.com (Postfix) with ESMTPSA id D0428616001; Tue, 10 Nov 2009 15:30:58 +0100 (CET) Date: Tue, 10 Nov 2009 15:30:58 +0100 (CET) Message-Id: <20091110.153058.215453052.mbj@tail-f.com> To: lhotka@cesnet.cz From: Martin Bjorklund In-Reply-To: <1257862910.25407.53.camel@missotis> References: <1257817369.7700.22.camel@missotis> <20091110.084812.181661537.mbj@tail-f.com> <1257862910.25407.53.camel@missotis> X-Mailer: Mew version 6.2.51 on Emacs 22.2 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=utf-8 Content-Transfer-Encoding: base64 Cc: netconf@ietf.org Subject: Re: [Netconf] 4741bis (007) - return from XPath filters X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Nov 2009 14:30:32 -0000 TGFkaXNsYXYgTGhvdGthIDxsaG90a2FAY2VzbmV0LmN6PiB3cm90ZToNCj4gTWFydGluIEJqb3Jr bHVuZCBww63FoWUgdiDDmnQgMTAuIDExLiAyMDA5IHYgMDg6NDggKzAxMDA6DQo+IA0KPiA+ID4g SSB0aGluayB0aGUgY2xlYW5lc3Qgc29sdXRpb24gd291bGQgYmUgdG8ganVzdCBkZWZpbmUgdGhl ICJzY2hlbWEiIGZvcg0KPiA+ID4gUlBDIHJlcXVlc3RzIHV0aWxpemluZyB0aGUgWFBhdGggY2Fw YWJpbGl0eSBhbmQgbGVhdmUgdGhlIHNwZWMgb2YgWFBhdGgNCj4gPiA+IHF1ZXJ5IHNlbWF0aWNz IHRvIFlBTkcgKG9yIG90aGVyIERNIGxhbmd1YWdlcywgZm9yIHRoYXQgbWF0dGVyKS4NCj4gPiAN Cj4gPiBJIHRoaW5rIHdlIGNhbiBhbmQgc2hvdWxkIGRvIGJldHRlci4gIFJlZ2FyZGxlc3Mgb2Yg RE0gbGFuZ3VhZ2UsIHdlDQo+ID4gd2FudCB0aGUgWFBhdGggZmlsdGVyIHRvIHJldHVybiBYTUwg ImFzIGZvciBzdWJ0cmVlIGZpbHRlcnMiLCByaWdodD8NCj4gDQo+IElzIHRoZSBzdWJ0cmVlIGZp bHRlcmluZyBtZWNoYW5pc20gc3VwcG9zZWQgdG8gZmlsbC1pbiBhbGwgImxpc3Qga2V5cyINCj4g aW4gdGhlIGFuY2VzdG9yIGhpZXJhcmNoeT8gV2hlcmUgaXMgdGhpcyBzYWlkPw0KDQpObywgc2Vl IG15IGZpcnN0IHBvc3QgaW4gdGhpcyB0aHJlYWQuICBJcyBtaWdodCBiZSB1c2VmdWwgdG8gYXQg bGVhc3QNCmFsbG93IHRoZSBzdWJ0cmVlIGZpbHRlcmluZyBtZWNoYW5pc20gdG8gZmlsbCBpbiBr ZXlzOyBBbmR5IGFuZCBEYXZpZA0KUi4gcmVwb3J0ZWQgdGhhdCB0aGVpciBpbXBsZW1lbnRhdGlv bnMgZG8gdGhpcy4NCg0KDQo+IEFueXdheSwgd2hhdCBpcyBpdCByZWFsbHkgc3VwcG9zZWQgdG8g bWVhbj8gSWYgSSBoYXZlDQo+IA0KPiBtb2R1bGUgZm9vIHsNCj4gICAgIG5hbWVzcGFjZSAiaHR0 cDovL2V4YW1wbGUub3JnL2ZvbyI7DQo+ICAgICBwcmVmaXggZm9vOw0KPiAgICAgY29udGFpbmVy IHRvcCB7DQo+ICAgICAgICAgbGlzdCBvdXRlciB7DQo+ICAgICAgICAgICAgIGtleSBvdXRlci1r ZXk7DQo+ICAgICAgICAgICAgIGxlYWYgb3V0ZXIta2V5IHsgLi4uIH0NCj4gICAgICAgICAgICAg bGlzdCBpbm5lciB7DQo+ICAgICAgICAgICAgICAgICBrZXkgaW5uZXIta2V5Ow0KPiAgICAgICAg ICAgICAgICAgbGVhZiBpbm5lci1rZXkgeyAuLi4gfQ0KPiAgICAgICAgICAgICAgICAgbGVhZiBi YXIgeyAuLi4gfQ0KPiAgICAgICAgICAgICB9DQo+ICAgICAgICAgfQ0KPiAgICAgfQ0KPiB9DQo+ IA0KPiBhbmQgdGhlbiB1c2UgWFBhdGggc2VsZWN0b3IgIi9mb286dG9wL2ZvbzpvdXRlci9mb286 aW5uZXIvZm9vOmJhciIsIHdpbGwNCj4gdGhlIHJldHVybmVkIG91dHB1dCBjb250YWluIGJvdGgg b3V0ZXIta2V5cyBhbmQgaW5uZXIta2V5cz8NCg0KWWVzLg0KDQoNCi9tYXJ0aW4NCg== From lhotka@cesnet.cz Tue Nov 10 15:16:03 2009 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4EE9F28C227 for ; Tue, 10 Nov 2009 15:16:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.25 X-Spam-Level: X-Spam-Status: No, score=-1.25 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904] 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 aQvN7Q+6+8pI for ; Tue, 10 Nov 2009 15:16:02 -0800 (PST) Received: from office2.cesnet.cz (office2.cesnet.cz [195.113.144.244]) by core3.amsl.com (Postfix) with ESMTP id 717E628C1AB for ; Tue, 10 Nov 2009 15:16:02 -0800 (PST) Received: from [133.93.113.127] (host-113-127.meeting.ietf.org [133.93.113.127]) by office2.cesnet.cz (Postfix) with ESMTP id 3AEABD800F0; Wed, 11 Nov 2009 00:16:26 +0100 (CET) From: Ladislav Lhotka To: Martin Bjorklund In-Reply-To: <20091110.153058.215453052.mbj@tail-f.com> References: <1257817369.7700.22.camel@missotis> <20091110.084812.181661537.mbj@tail-f.com> <1257862910.25407.53.camel@missotis> <20091110.153058.215453052.mbj@tail-f.com> Content-Type: text/plain; charset="UTF-8" Organization: CESNET Date: Wed, 11 Nov 2009 08:16:22 +0900 Message-Id: <1257894982.32075.5.camel@missotis> Mime-Version: 1.0 X-Mailer: Evolution 2.26.1 Content-Transfer-Encoding: 8bit Cc: netconf@ietf.org Subject: Re: [Netconf] 4741bis (007) - return from XPath filters X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Nov 2009 23:16:03 -0000 Martin Bjorklund píše v Út 10. 11. 2009 v 15:30 +0100: > Ladislav Lhotka wrote: > > Martin Bjorklund píše v Út 10. 11. 2009 v 08:48 +0100: > > > > > > I think the cleanest solution would be to just define the "schema" for > > > > RPC requests utilizing the XPath capability and leave the spec of XPath > > > > query sematics to YANG (or other DM languages, for that matter). > > > > > > I think we can and should do better. Regardless of DM language, we > > > want the XPath filter to return XML "as for subtree filters", right? > > > > Is the subtree filtering mechanism supposed to fill-in all "list keys" > > in the ancestor hierarchy? Where is this said? > > No, see my first post in this thread. Is might be useful to at least > allow the subtree filtering mechanism to fill in keys; Andy and David > R. reported that their implementations do this. The original RFC 4741 behaviour should remain compliant. In principle, there needn't be any key-like distinguishing elements/attributes. For example, the datastore content may be the following valid XML: 75 75 Lada -- Ladislav Lhotka, CESNET PGP Key ID: E74E8C0C From andy@netconfcentral.com Tue Nov 10 16:06:09 2009 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 33A663A6B30 for ; Tue, 10 Nov 2009 16:06:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.092 X-Spam-Level: X-Spam-Status: No, score=-2.092 tagged_above=-999 required=5 tests=[AWL=0.172, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, UNPARSEABLE_RELAY=0.001] 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 VnpdPwkJ5p05 for ; Tue, 10 Nov 2009 16:06:08 -0800 (PST) Received: from smtp127.sbc.mail.sp1.yahoo.com (smtp127.sbc.mail.sp1.yahoo.com [69.147.65.186]) by core3.amsl.com (Postfix) with SMTP id 7B4383A68F1 for ; Tue, 10 Nov 2009 16:06:08 -0800 (PST) Received: (qmail 73747 invoked from network); 11 Nov 2009 00:06:33 -0000 Received: from adsl-67-125-158-26.dsl.irvnca.pacbell.net (andy@67.125.158.26 with plain) by smtp127.sbc.mail.sp1.yahoo.com with SMTP; 10 Nov 2009 16:06:33 -0800 PST X-Yahoo-SMTP: Z6xhxCCswBAlhcxjVNwaQtp4EKpLdTUUf5Nx_pGy81o- X-YMail-OSG: SBdyNMcVM1mBtPnbbIm5kLhsiT2ZtYCvFNq4VH6xUoDb0j7VWq.jowKwmI40HfZlUV2sNn89m0VrQaTKi1D8kgstoYIubl1yDQNKACPOQBvcrQ9qA7qcW8_Qf64TJaZZTne2QCE7c5wnxQAok2xplbRMsb4nwBqmp0kiYN_9d9Lox.fUorjAdJPUfFnKjhl_xleiP.2LLiKSa0.0O5LZTPFMm7IcGinKnX3YT.xh2PQf93yrMBVAyus0OtSQ1YggmgVyvQFJxT96iEXCbUbIZevkSUzvMEW9uwn3vyXIVFuYKkLc5.V9T595oEphIm_RdYClgY2IrArwZiOh.aOPMghaBVYVzys_u0WDMx7zJXcS X-Yahoo-Newman-Property: ymail-3 Message-ID: <4AFA000D.4010708@netconfcentral.com> Date: Tue, 10 Nov 2009 16:06:37 -0800 From: Andy Bierman User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: Ladislav Lhotka References: <1257817369.7700.22.camel@missotis> <20091110.084812.181661537.mbj@tail-f.com> <1257862910.25407.53.camel@missotis> <20091110.153058.215453052.mbj@tail-f.com> <1257894982.32075.5.camel@missotis> In-Reply-To: <1257894982.32075.5.camel@missotis> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Cc: netconf@ietf.org Subject: Re: [Netconf] 4741bis (007) - return from XPath filters X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Nov 2009 00:06:09 -0000 Ladislav Lhotka wrote: > Martin Bjorklund píše v Út 10. 11. 2009 v 15:30 +0100: >> Ladislav Lhotka wrote: >>> Martin Bjorklund píše v Út 10. 11. 2009 v 08:48 +0100: >>> >>>>> I think the cleanest solution would be to just define the "schema" for >>>>> RPC requests utilizing the XPath capability and leave the spec of XPath >>>>> query sematics to YANG (or other DM languages, for that matter). >>>> I think we can and should do better. Regardless of DM language, we >>>> want the XPath filter to return XML "as for subtree filters", right? >>> Is the subtree filtering mechanism supposed to fill-in all "list keys" >>> in the ancestor hierarchy? Where is this said? >> No, see my first post in this thread. Is might be useful to at least >> allow the subtree filtering mechanism to fill in keys; Andy and David >> R. reported that their implementations do this. > > The original RFC 4741 behaviour should remain compliant. In principle, > there needn't be any key-like distinguishing elements/attributes. For > example, the datastore content may be the following valid XML: > > > 75 > 75 > > I don't see why it is a problem if the server fills in the missing keys. If there are no keys, like in your example, then there will be no added leafs. But what if the 'toaster' is a list: 1 75 2 234 This way, the client will use its YANG definition, see that /toaster is a list, and expect a key leaf to be the first element returned after that. Consider the utility if no list key is returned: Which toaster is on fire? IMO, not only should the server return keys. it should also normalize the output so no duplicates are returned: 2 234 > Lada > Andy From bertietf@bwijnen.net Tue Nov 10 18:07:41 2009 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C2FF93A6BE4 for ; Tue, 10 Nov 2009 18:07:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.445 X-Spam-Level: X-Spam-Status: No, score=-9.445 tagged_above=-999 required=5 tests=[AWL=1.154, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] 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 sLP83GoNF4nL for ; Tue, 10 Nov 2009 18:07:40 -0800 (PST) Received: from postgirl.ripe.net (postgirl.ripe.net [193.0.19.66]) by core3.amsl.com (Postfix) with ESMTP id BAC6C3A6BE5 for ; Tue, 10 Nov 2009 18:07:39 -0800 (PST) Received: from herring.ripe.net ([193.0.1.203]) by postgirl.ripe.net with esmtp (Exim 4.63) (envelope-from ) id 1N82cn-0001lg-8F for netconf@ietf.org; Wed, 11 Nov 2009 03:08:02 +0100 Received: from host-24-71.meeting.ietf.org (dog.ripe.net [193.0.1.217]) by herring.ripe.net (Postfix) with ESMTP id 7B4F12F583 for ; Wed, 11 Nov 2009 03:07:56 +0100 (CET) Message-ID: <4AFA1C7A.6030809@bwijnen.net> Date: Wed, 11 Nov 2009 11:07:54 +0900 From: "Bert (IETF) Wijnen" User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: Netconf Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-RIPE-Spam-Level: ---- X-RIPE-Signature: 86ab03e524994f79ca2c75a176445dd44652d05f397a352efd5d961b2a2aa290 Subject: [Netconf] comment ons draft-ietf-netconf-with-defaults-04.txt] X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Nov 2009 02:07:41 -0000 just some late editorial comments that you might consider if a new rev gets done - sect 1.2 2nd para As a consequence of this issue, maybe better to s/issue/approach/ - section 9 add a note to rfc-editor to remove section 9 when doc gets published as rfc - I see that you use [RFC2119] for citation and [NETCONF] I prefer consistency and would personally use [RFC4741] to be consistent with citations to other RFCs. personal taste of course. Not a bug Bert From lhotka@cesnet.cz Tue Nov 10 20:35:11 2009 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 285D53A67AF for ; Tue, 10 Nov 2009 20:35:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.25 X-Spam-Level: X-Spam-Status: No, score=-1.25 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904] 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 ErHX0aXEtD2C for ; Tue, 10 Nov 2009 20:35:10 -0800 (PST) Received: from office2.cesnet.cz (office2.cesnet.cz [195.113.144.244]) by core3.amsl.com (Postfix) with ESMTP id 2141C3A687B for ; Tue, 10 Nov 2009 20:35:10 -0800 (PST) Received: from [133.93.32.206] (host-32-206.meeting.ietf.org [133.93.32.206]) by office2.cesnet.cz (Postfix) with ESMTP id D980BD800CE; Wed, 11 Nov 2009 05:35:35 +0100 (CET) From: Ladislav Lhotka To: Andy Bierman In-Reply-To: <4AFA000D.4010708@netconfcentral.com> References: <1257817369.7700.22.camel@missotis> <20091110.084812.181661537.mbj@tail-f.com> <1257862910.25407.53.camel@missotis> <20091110.153058.215453052.mbj@tail-f.com> <1257894982.32075.5.camel@missotis> <4AFA000D.4010708@netconfcentral.com> Content-Type: text/plain; charset="UTF-8" Organization: CESNET Date: Wed, 11 Nov 2009 13:35:26 +0900 Message-Id: <1257914126.8054.30.camel@missotis> Mime-Version: 1.0 X-Mailer: Evolution 2.26.1 Content-Transfer-Encoding: 8bit Cc: netconf@ietf.org Subject: Re: [Netconf] 4741bis (007) - return from XPath filters X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Nov 2009 04:35:11 -0000 Andy Bierman píše v Út 10. 11. 2009 v 16:06 -0800: > > > > The original RFC 4741 behaviour should remain compliant. In principle, > > there needn't be any key-like distinguishing elements/attributes. For > > example, the datastore content may be the following valid XML: > > > > > > 75 > > 75 > > > > > > I don't see why it is a problem if the server fills in the > missing keys. If there are no keys, like in your example, > then there will be no added leafs. But what if the 'toaster' > is a list: I don't mind if the server fills in the keys but I'd object if the server was no more allowed to return multiple identical trees, like in this example. But the fact that the replies to get/get-config queries with both subtree and XPath filters may depend on the data modeling framework is a new situation compared to the old RFC 4741. Lada > > > > > > > > > > > 1 > 75 > > > 2 > 234 > > > > > This way, the client will use its YANG definition, > see that /toaster is a list, and expect a key leaf > to be the first element returned after that. > > Consider the utility if no list key is returned: > > > > > > > > > > > > > > Which toaster is on fire? > > > IMO, not only should the server return keys. it should > also normalize the output so no duplicates are returned: > > > > > > > > > > > > > > 2 > > 234 > > > > > > Lada > > > > Andy -- Ladislav Lhotka, CESNET PGP Key ID: E74E8C0C From bertietf@bwijnen.net Tue Nov 10 21:17:07 2009 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 47ADF28C28F for ; Tue, 10 Nov 2009 21:17:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.528 X-Spam-Level: X-Spam-Status: No, score=-5.528 tagged_above=-999 required=5 tests=[AWL=-2.929, BAYES_00=-2.599] 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 d5FMmZBhyTbm for ; Tue, 10 Nov 2009 21:17:06 -0800 (PST) Received: from postlady.ripe.net (postlady.ripe.net [193.0.19.65]) by core3.amsl.com (Postfix) with ESMTP id 3613628C28E for ; Tue, 10 Nov 2009 21:17:05 -0800 (PST) Received: from herring.ripe.net ([193.0.1.203]) by postlady.ripe.net with esmtp (Exim 4.63) (envelope-from ) id 1N85a8-0007WA-KL for netconf@ietf.org; Wed, 11 Nov 2009 06:17:30 +0100 Received: from host-24-71.meeting.ietf.org (dog.ripe.net [193.0.1.217]) by herring.ripe.net (Postfix) with ESMTP id EE8B32F583 for ; Wed, 11 Nov 2009 06:17:23 +0100 (CET) Message-ID: <4AFA48E2.9010900@bwijnen.net> Date: Wed, 11 Nov 2009 14:17:22 +0900 From: "Bert (IETF) Wijnen" User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: Netconf Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable X-RIPE-Spam-Level: ---- X-RIPE-Signature: 86ab03e524994f79ca2c75a176445dd4c193d91066f97df8d5a13a4567ffb62d Subject: Re: [Netconf] #7: URI assignments for IANA] X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Nov 2009 05:17:07 -0000 netconf WG members, do not get worried by these sort of messages. The WG chairs attended a WG-chairs session over lunch today, and the topic was issue tracking. So I played with the issues recorden under the "Issues" button on web pag= e http://tools.ietf.org/wg/netconf/ I have closed the issues that were recorded for notifications. I think we addressed them in the RFC we published. I played with one of the items against rfc4741. Was trying to see if I could see the results on the page that lists the active drafts. it seemed to work for a while but now I don't see it working anymore. Need to test more. But anyway, Martin is keeping track of 4741bis issues in a separate page under the "wiki" button. So Mehmet may close the 4741bis items after making sure they are all in Martin's list. I will be work make sure we have all 4742 issues listed... later in the week probably Bert Netconf wrote: > #7: URI assignments for IANA > ---------------------------------------------+-------------------------= ----- > Reporter: ietf@=E2=80=A6 | Owner: = =20 > Type: task | Status: closed > Priority: major | Milestone: =20 > Component: draft-ietf-netconf-notification | Version: =20 > Severity: Submitted WG Document | Resolution: fixed=20 > Keywords: | =20 > ---------------------------------------------+-------------------------= ----- > Changes (by bertietf@=E2=80=A6): > > * status: new =3D> closed > * resolution: =3D> fixed > * severity: =3D> Submitted WG Document > > > =20 From mehmet.ersue@nsn.com Wed Nov 11 00:26:02 2009 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 861D73A6C44 for ; Wed, 11 Nov 2009 00:26:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.67 X-Spam-Level: X-Spam-Status: No, score=-2.67 tagged_above=-999 required=5 tests=[AWL=-0.072, BAYES_00=-2.599, HTML_MESSAGE=0.001] 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 FM5-4R0DUhj8 for ; Wed, 11 Nov 2009 00:26:01 -0800 (PST) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [93.183.12.31]) by core3.amsl.com (Postfix) with ESMTP id C57A23A6C3E for ; Wed, 11 Nov 2009 00:25:57 -0800 (PST) Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id nAB8QHNw017436 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 11 Nov 2009 09:26:18 +0100 Received: from demuexc024.nsn-intra.net (demuexc024.nsn-intra.net [10.159.32.11]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id nAB8QCKF004010; Wed, 11 Nov 2009 09:26:17 +0100 Received: from DEMUEXC006.nsn-intra.net ([10.150.128.18]) by demuexc024.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 11 Nov 2009 09:26:13 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CA62A8.A0CE41F0" Date: Wed, 11 Nov 2009 09:26:11 +0100 Message-ID: <80A0822C5E9A4440A5117C2F4CD36A64125EF2@DEMUEXC006.nsn-intra.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Short Summary of the IETF 76 NETCONF WG Session Thread-Index: AcpiqJ/59SgbW5F6SRas5F2ecG7BAA== From: "Ersue, Mehmet (NSN - DE/Munich)" To: X-OriginalArrivalTime: 11 Nov 2009 08:26:13.0031 (UTC) FILETIME=[A1197B70:01CA62A8] Cc: netconf@ietf.org Subject: [Netconf] Short Summary of the IETF 76 NETCONF WG Session X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Nov 2009 08:26:02 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CA62A8.A0CE41F0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Dan, please find below a short summary of the NETCONF WG session on MONDAY, November 9, 2009, 15:20-17:20 at IETF 76: - We had approx. 38 persons in the 2 hour session for NETCONF WG. - We reviewed the status of the WG - We went through the chartered WG items and had a good discussion and review of the documents. - Partial Lock RPC for NETCONF is in RFC Editor's queue. - NETCONF Monitoring needs a few corrections and an update before it can go to AD review.=20 We need to do better tracking and address the issues. - 4741bis issue solving is ongoing. Discussion will be continued on the maillist. - With-defaults draft has some issues left which will be discussed and solved on the maillist before WGLC. - The WG is in favor of preparing a 4742bis draft with known errata and issues. The charter allows this work already and the co-chairs will prepare charter milestone update after maillist approval for 4742bis. - The not-chartered draft "Robust Configuration Management within NETCONF" will be updated for IETF 77.=20 Cheers, Bert & Mehmet ------_=_NextPart_001_01CA62A8.A0CE41F0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Short Summary of the IETF 76 NETCONF WG Session

Hi Dan,

please find below a short summary of = the NETCONF WG session on MONDAY, November 9, 2009, 15:20-17:20 at IETF = 76:

- We had approx. 38 persons in the 2 = hour session for NETCONF WG.
- We reviewed the status of the = WG
- We went through the chartered WG = items and had a good discussion and review of the documents.

- Partial Lock RPC for NETCONF is in = RFC Editor's queue.
- NETCONF Monitoring needs a few = corrections and an update before it can go to AD review.
We need to do better tracking and = address the issues.
- 4741bis issue solving is ongoing. = Discussion will be continued on the maillist.
- With-defaults draft has some = issues left which will be discussed and solved on the maillist before = WGLC.

- The WG is in favor of preparing a = 4742bis draft with known errata and issues. The charter allows this work = already and the co-chairs will prepare charter milestone update after = maillist approval for 4742bis.

- The not-chartered draft = "Robust Configuration Management within NETCONF" will be = updated for IETF 77.

Cheers,
Bert & Mehmet

------_=_NextPart_001_01CA62A8.A0CE41F0-- From mehmet.ersue@nsn.com Wed Nov 11 00:34:56 2009 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 08D923A695C for ; Wed, 11 Nov 2009 00:34:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.665 X-Spam-Level: X-Spam-Status: No, score=-2.665 tagged_above=-999 required=5 tests=[AWL=-0.067, BAYES_00=-2.599, HTML_MESSAGE=0.001] 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 YEw9xKXPFpVU for ; Wed, 11 Nov 2009 00:34:55 -0800 (PST) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [93.183.12.32]) by core3.amsl.com (Postfix) with ESMTP id 186823A67FF for ; Wed, 11 Nov 2009 00:34:24 -0800 (PST) Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd001.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id nAB8YnAZ019792 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 11 Nov 2009 09:34:49 +0100 Received: from demuexc024.nsn-intra.net (demuexc024.nsn-intra.net [10.159.32.11]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id nAB8Ynlg001246; Wed, 11 Nov 2009 09:34:49 +0100 Received: from DEMUEXC006.nsn-intra.net ([10.150.128.18]) by demuexc024.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 11 Nov 2009 09:34:48 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CA62A9.D43FF8D4" Date: Wed, 11 Nov 2009 09:34:47 +0100 Message-ID: <80A0822C5E9A4440A5117C2F4CD36A64125EFA@DEMUEXC006.nsn-intra.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Action Items after the IETF 76 NETCONF WG Session Thread-Index: AcpiqdN15Avg2qUhSz6raoCh/9uKYQ== From: "Ersue, Mehmet (NSN - DE/Munich)" To: X-OriginalArrivalTime: 11 Nov 2009 08:34:48.0803 (UTC) FILETIME=[D4860B30:01CA62A9] Subject: [Netconf] Action Items after the IETF 76 NETCONF WG Session X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Nov 2009 08:34:56 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CA62A9.D43FF8D4 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi All, below are the action items we wrote down after the NETCONF WG session on Monday.=20 Document editors please drive your part. AI - Mark, Martin, Balazs: Bring issues from the session to the maillist and drive the discussion. AI - Mark, Martin, Balazs: Update the documents based on the issue discussion result. AI - Bert: Check with Margaret Wassermann whether she committs to take over the editorship for 4742bis draft and ask the WG for consensus for preparing a 4742bis document. AI - Bert: Update charter milestones AI - Mehmet: Check with Martin B whether the 4741 issues on the WG issue tracker are redundant with the issue list he maintains and can be deleted. Mehmet to delete those issues on WG issue tracker. AI - Mehmet: Ask Mark Scott to add a Change Log to the Monitoring document AI - Mehmet: Agree with Mark and add issues from Monitoring discussion to the WG issue tracker=20 AI - Bert: Add 4742bis relevant issues to the WG issue tracker=20 Cheers, Bert and Mehmet ------_=_NextPart_001_01CA62A9.D43FF8D4 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Action Items after the IETF 76 NETCONF WG Session

Hi All,

below are the action items we wrote = down after the NETCONF WG session on Monday.
Document editors please drive your = part.

AI - Mark, Martin, Balazs: Bring = issues from the session to the maillist and drive the discussion.
AI - Mark, Martin, Balazs: Update = the documents based on the issue discussion result.

AI - Bert: Check with Margaret = Wassermann whether she committs to take over the editorship for 4742bis = draft and ask the WG for consensus for preparing a 4742bis = document.

AI - Bert: Update charter = milestones

AI - Mehmet: Check with Martin B = whether the 4741 issues on the WG issue tracker are redundant with the = issue list he maintains and can be deleted. Mehmet to delete those = issues on WG issue tracker.

AI - Mehmet: Ask Mark Scott to add a = Change Log to the Monitoring document
AI - Mehmet: Agree with Mark and add = issues from Monitoring discussion to the WG issue tracker
AI - Bert: Add 4742bis relevant = issues to the WG issue tracker

Cheers,
Bert and = Mehmet

------_=_NextPart_001_01CA62A9.D43FF8D4-- From bertietf@bwijnen.net Wed Nov 11 04:02:05 2009 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8E2E63A6961; Wed, 11 Nov 2009 04:02:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.332 X-Spam-Level: X-Spam-Status: No, score=-5.332 tagged_above=-999 required=5 tests=[AWL=-2.733, BAYES_00=-2.599] 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 UGKGuEaM5qKk; Wed, 11 Nov 2009 04:02:04 -0800 (PST) Received: from postlady.ripe.net (postlady.ripe.net [193.0.19.65]) by core3.amsl.com (Postfix) with ESMTP id B8BAA28C168; Wed, 11 Nov 2009 04:02:04 -0800 (PST) Received: from herring.ripe.net ([193.0.1.203]) by postlady.ripe.net with esmtp (Exim 4.63) (envelope-from ) id 1N8Bu6-0004o2-OF; Wed, 11 Nov 2009 13:02:32 +0100 Received: from host-24-71.meeting.ietf.org (dog.ripe.net [193.0.1.217]) by herring.ripe.net (Postfix) with ESMTP id 627892F5B3; Wed, 11 Nov 2009 13:02:24 +0100 (CET) Message-ID: <4AFAA7CF.3050005@bwijnen.net> Date: Wed, 11 Nov 2009 21:02:23 +0900 From: "Bert (IETF) Wijnen" User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: netmod@ietf.org, Netconf Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-RIPE-Spam-Level: ---- X-RIPE-Signature: 86ab03e524994f79ca2c75a176445dd430b4bc464d33bedb8573fdee82c25a72 Subject: [Netconf] FYI - netconf/netmod for ietfSmartGrid ?] X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Nov 2009 12:02:05 -0000 I am sitting in the IETF-smartGrid BarBof here. Hiroshi Esaki is presenting the approach they aretaking in Japan. He lists XML-Conf as a protocol for configuration. He clarified that he meant netconf. Maybe this is a place to get some YANG modules defined as well? Some of the discussion here will be what can be done in IETF in terms of standardization. Bert From robert.cole@jhuapl.edu Wed Nov 11 06:03:56 2009 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 33E4228C19A for ; Wed, 11 Nov 2009 06:03:56 -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=[AWL=-0.001, BAYES_00=-2.599, HTML_MESSAGE=0.001] 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 8DSbETIaCuTN for ; Wed, 11 Nov 2009 06:03:55 -0800 (PST) Received: from jhuapl.edu (pilot.jhuapl.edu [128.244.198.200]) by core3.amsl.com (Postfix) with ESMTP id 5658528C184 for ; Wed, 11 Nov 2009 06:03:41 -0800 (PST) Received: from ([128.244.198.90]) by pilot.jhuapl.edu with ESMTP with TLS id 63GHCH1.33924676; Wed, 11 Nov 2009 09:02:55 -0500 Received: from aplesstar.dom1.jhuapl.edu ([128.244.198.212]) by aplexcas1.dom1.jhuapl.edu ([128.244.198.90]) with mapi; Wed, 11 Nov 2009 09:03:22 -0500 From: "Cole, Robert G." To: "Ersue, Mehmet (NSN - DE/Munich)" , "dromasca@avaya.com" , "andy@netconfcentral.com" Date: Wed, 11 Nov 2009 09:03:20 -0500 Thread-Topic: Short Summary of the IETF 76 NETCONF WG Session Thread-Index: AcpiqJ/59SgbW5F6SRas5F2ecG7BAAALlSIA Message-ID: <0A8F66C42F49E448A40E99946404EE5B717816A7B4@aplesstar.dom1.jhuapl.edu> References: <80A0822C5E9A4440A5117C2F4CD36A64125EF2@DEMUEXC006.nsn-intra.net> In-Reply-To: <80A0822C5E9A4440A5117C2F4CD36A64125EF2@DEMUEXC006.nsn-intra.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_0A8F66C42F49E448A40E99946404EE5B717816A7B4aplesstardom1_" MIME-Version: 1.0 Cc: "netconf@ietf.org" Subject: Re: [Netconf] Short Summary of the IETF 76 NETCONF WG Session X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Nov 2009 14:03:56 -0000 --_000_0A8F66C42F49E448A40E99946404EE5B717816A7B4aplesstardom1_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Mehmet, Bert, Yes, we'll definitely update the "Robust NETCONF" draft for IETF 77. It ju= st seemed that NETCONF/NETMOD had enough on its plate for this meeting. Th= erefore, we thought it best to hold off this activity this time around. Thanks, Bob ________________________________ From: netconf-bounces@ietf.org [mailto:netconf-bounces@ietf.org] On Behalf = Of Ersue, Mehmet (NSN - DE/Munich) Sent: Wednesday, November 11, 2009 3:26 AM To: dromasca@avaya.com Cc: netconf@ietf.org Subject: [Netconf] Short Summary of the IETF 76 NETCONF WG Session Hi Dan, please find below a short summary of the NETCONF WG session on MONDAY, Nove= mber 9, 2009, 15:20-17:20 at IETF 76: - We had approx. 38 persons in the 2 hour session for NETCONF WG. - We reviewed the status of the WG - We went through the chartered WG items and had a good discussion and revi= ew of the documents. - Partial Lock RPC for NETCONF is in RFC Editor's queue. - NETCONF Monitoring needs a few corrections and an update before it can go= to AD review. We need to do better tracking and address the issues. - 4741bis issue solving is ongoing. Discussion will be continued on the mai= llist. - With-defaults draft has some issues left which will be discussed and solv= ed on the maillist before WGLC. - The WG is in favor of preparing a 4742bis draft with known errata and iss= ues. The charter allows this work already and the co-chairs will prepare ch= arter milestone update after maillist approval for 4742bis. - The not-chartered draft "Robust Configuration Management within NETCONF" = will be updated for IETF 77. Cheers, Bert & Mehmet --_000_0A8F66C42F49E448A40E99946404EE5B717816A7B4aplesstardom1_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Short Summary of the IETF 76 NETCONF WG Session
Mehmet,
Bert,
 
Yes, we'll definitely update the "Robust NETCONF= " draft=20 for IETF 77.  It just seemed that NETCONF/NETMOD had enough on its pla= te=20 for this meeting.  Therefore, we thought it best to hold off this acti= vity=20 this time around.
 
Thanks,
Bob

From: netconf-bounces@ietf.org=20 [mailto:netconf-bounces@ietf.org] On Behalf Of Ersue, Mehmet (NSN -= =20 DE/Munich)
Sent: Wednesday, November 11, 2009 3:26 AM
To:=20 dromasca@avaya.com
Cc: netconf@ietf.org
Subject: [Netco= nf]=20 Short Summary of the IETF 76 NETCONF WG Session


Hi Dan,

please find below a short summary of the N= ETCONF WG=20 session on MONDAY, November 9, 2009, 15:20-17:20 at IETF 76:

- We had approx. 38 persons in the 2 hour = session=20 for NETCONF WG.
- We reviewed the = status of=20 the WG
- We went through the chart= ered WG=20 items and had a good discussion and review of the documents.

- Partial Lock RPC for NETCONF is in RFC E= ditor's=20 queue.
- NETCONF Monitoring needs = a few=20 corrections and an update before it can go to AD review.
We need to do better tracking and address the issue= s.=20
- 4741bis issue solving is ongoing. Discu= ssion=20 will be continued on the maillist.
-=20 With-defaults draft has some issues left which will be discussed and solved= on=20 the maillist before WGLC.

- The WG is in favor of preparing a 4742bi= s draft=20 with known errata and issues. The charter allows this work already and the= =20 co-chairs will prepare charter milestone update after maillist approval for= =20 4742bis.

- The not-chartered draft "Robust Configur= ation=20 Management within NETCONF" will be updated for IETF 77.

Cheers,
Bert=20 & Mehmet

--_000_0A8F66C42F49E448A40E99946404EE5B717816A7B4aplesstardom1_-- From MARKSCOT@nortel.com Wed Nov 11 08:47:37 2009 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 084943A6ACF for ; Wed, 11 Nov 2009 08:47:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 WTqHvxpxIf45 for ; Wed, 11 Nov 2009 08:47:36 -0800 (PST) Received: from zcars04e.nortel.com (zcars04e.nortel.com [47.129.242.56]) by core3.amsl.com (Postfix) with ESMTP id EF1123A6ACD for ; Wed, 11 Nov 2009 08:47:35 -0800 (PST) Received: from zcarhxm0.corp.nortel.com (zcarhxm0.corp.nortel.com [47.129.230.95]) by zcars04e.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id nABGlxt01507; Wed, 11 Nov 2009 16:47:59 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 11 Nov 2009 11:47:51 -0500 Message-ID: <085091CB2CA14E4B8B163FFC37C84E9D1AE8C6FD@zcarhxm0.corp.nortel.com> In-Reply-To: <001b01ca5ca4$ad010e80$6801a8c0@oemcomputer> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Netconf] draft-ietf-netconf-monitoring-09 last call commentsfrom js Thread-Index: AcpcrQzbHZER5BJ4RMOHUPZgkys/twGQJ59w References: <20091103142239.GA7302@elstar.local><200911031432.nA3EWxSg065216@idle.juniper.net><20091103152233.GA7621@elstar.local> <001b01ca5ca4$ad010e80$6801a8c0@oemcomputer> From: "Mark Scott" To: "Randy Presuhn" , Subject: Re: [Netconf] draft-ietf-netconf-monitoring-09 last call commentsfrom js X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Nov 2009 16:47:37 -0000 Juergen and Randy, I can't speak for how many implementers actually read both the RFC and associated MIBs, but in the YANG module we have included references to the related RFCs, descriptions of the monitored data, and where required the behavior (e.g. the rpc definition). Do you have specific examples of additional text from the RFC which should be included in the module Mark -----Original Message----- From: netconf-bounces@ietf.org [mailto:netconf-bounces@ietf.org] On Behalf Of Randy Presuhn Sent: Tuesday, November 03, 2009 11:43 AM To: netconf@ietf.org Subject: Re: [Netconf] draft-ietf-netconf-monitoring-09 last call commentsfrom js Hi - > From: "Juergen Schoenwaelder" > To: "Phil Shafer" > Cc: > Sent: Tuesday, November 03, 2009 8:22 AM > Subject: Re: [Netconf] draft-ietf-netconf-monitoring-09 last call comments from js ... > > And given the number of mib implementors that seem to not read the > > rfc, just the mib, I'd vote to have all real text live within the > > yang module. >=20 > We both agree on the principle - I just disagree with your citation of > RFC 3412 in an attempt to prove me wrong that the SMIv2 practice has > been for a long time to have MIB modules self-contained. I agree with Juergen. Yes, the stuff relevant to management should be in the MIB module. However, most RFCs with MIBs describe a system or protocol that actually *does* something other than just sit around and be managed, and many of these operational characteristics are not (and should not) be subject to management control or monitoring. Such information does not belong in a MIB module. Randy _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From MARKSCOT@nortel.com Wed Nov 11 08:58:57 2009 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2075D3A6ADD for ; Wed, 11 Nov 2009 08:58:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 c1n2ZaiJ3ofz for ; Wed, 11 Nov 2009 08:58:56 -0800 (PST) Received: from zrtps0kp.nortel.com (zrtps0kp.nortel.com [47.140.192.56]) by core3.amsl.com (Postfix) with ESMTP id 5C5603A6971 for ; Wed, 11 Nov 2009 08:58:30 -0800 (PST) Received: from zcarhxm0.corp.nortel.com (zcarhxm0.corp.nortel.com [47.129.230.95]) by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id nABGwqZ10250; Wed, 11 Nov 2009 16:58:52 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 11 Nov 2009 11:58:49 -0500 Message-ID: <085091CB2CA14E4B8B163FFC37C84E9D1AE8C736@zcarhxm0.corp.nortel.com> In-Reply-To: <20091103.160400.23684688.mbj@tail-f.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Netconf] draft-ietf-netconf-monitoring-09 last call comments from js Thread-Index: AcpclvEW9bnWoRS4TDSR9hloWtYOgQGWOW7g References: <20091103142239.GA7302@elstar.local><200911031432.nA3EWxSg065216@idle.juniper.net> <20091103.160400.23684688.mbj@tail-f.com> From: "Mark Scott" To: "Martin Bjorklund" , Cc: netconf@ietf.org Subject: Re: [Netconf] draft-ietf-netconf-monitoring-09 last call comments from js X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Nov 2009 16:58:57 -0000 Martin, Related to the reply I posted to Juergen and Randy on this thread: By descriptive text I assume we mean only the text for each parm in sec 2 specifically. In which case are we effectively saying that 'see yang module for details' is sufficient for sec 2? If not, can someone help me better understand which descriptive text belongs in the yang module (to augment what is already there) and which should remain in sec 2 of the RFC? Mark -----Original Message----- From: netconf-bounces@ietf.org [mailto:netconf-bounces@ietf.org] On Behalf Of Martin Bjorklund Sent: Tuesday, November 03, 2009 10:04 AM To: phil@juniper.net Cc: netconf@ietf.org Subject: Re: [Netconf] draft-ietf-netconf-monitoring-09 last call comments from js Phil Shafer wrote: > And given the number of mib implementors that seem to not read the > rfc, just the mib, I'd vote to have all real text live within the > yang module. I also agree. For this particular document, it started out with an XSD model, and having all the text in the XSD was not very readable. But now that we moved to YANG, I agree that descriptive text should be moved into the description clauses. /martin _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From mbj@tail-f.com Wed Nov 11 12:43:57 2009 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C37D03A6784 for ; Wed, 11 Nov 2009 12:43:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.99 X-Spam-Level: X-Spam-Status: No, score=-1.99 tagged_above=-999 required=5 tests=[AWL=0.056, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] 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 rL5HU0zte86I for ; Wed, 11 Nov 2009 12:43:57 -0800 (PST) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id 0ACBF3A67A8 for ; Wed, 11 Nov 2009 12:43:56 -0800 (PST) Received: from localhost (c213-100-167-236.swipnet.se [213.100.167.236]) by mail.tail-f.com (Postfix) with ESMTPSA id 07EF2616001; Wed, 11 Nov 2009 21:44:24 +0100 (CET) Date: Wed, 11 Nov 2009 21:44:23 +0100 (CET) Message-Id: <20091111.214423.197351074.mbj@tail-f.com> To: markscot@nortel.com From: Martin Bjorklund In-Reply-To: <085091CB2CA14E4B8B163FFC37C84E9D1AE8C736@zcarhxm0.corp.nortel.com> References: <200911031432.nA3EWxSg065216@idle.juniper.net> <20091103.160400.23684688.mbj@tail-f.com> <085091CB2CA14E4B8B163FFC37C84E9D1AE8C736@zcarhxm0.corp.nortel.com> X-Mailer: Mew version 6.2.51 on Emacs 22.2 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: netconf@ietf.org Subject: Re: [Netconf] draft-ietf-netconf-monitoring-09 last call comments from js X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Nov 2009 20:43:57 -0000 "Mark Scott" wrote: > Martin, > > Related to the reply I posted to Juergen and Randy on this thread: > > By descriptive text I assume we mean only the text for each parm in sec > 2 specifically. In which case are we effectively saying that 'see yang > module for details' is sufficient for sec 2? One option is to remove section 2 and 3, and make sure all details are moved to the YANG module. However, it might be nice to keep an overview, like the one in section 2.1. /martin From j.schoenwaelder@jacobs-university.de Wed Nov 11 14:21:06 2009 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7AAA53A68A6 for ; Wed, 11 Nov 2009 14:21:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.956 X-Spam-Level: X-Spam-Status: No, score=-1.956 tagged_above=-999 required=5 tests=[AWL=0.293, BAYES_00=-2.599, HELO_EQ_DE=0.35] 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 M+-sYEU2jnXC for ; Wed, 11 Nov 2009 14:21:05 -0800 (PST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 84D853A685A for ; Wed, 11 Nov 2009 14:21:05 -0800 (PST) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 90576C002B; Wed, 11 Nov 2009 23:21:33 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius3.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id ge1ABMIIwye4; Wed, 11 Nov 2009 23:21:32 +0100 (CET) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 951CFC0019; Wed, 11 Nov 2009 23:21:32 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 60071E18E14; Wed, 11 Nov 2009 23:21:31 +0100 (CET) Date: Wed, 11 Nov 2009 23:21:31 +0100 From: Juergen Schoenwaelder To: Martin Bjorklund Message-ID: <20091111222131.GA2218@elstar.local> Mail-Followup-To: Martin Bjorklund , "markscot@nortel.com" , "netconf@ietf.org" References: <200911031432.nA3EWxSg065216@idle.juniper.net> <20091103.160400.23684688.mbj@tail-f.com> <085091CB2CA14E4B8B163FFC37C84E9D1AE8C736@zcarhxm0.corp.nortel.com> <20091111.214423.197351074.mbj@tail-f.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20091111.214423.197351074.mbj@tail-f.com> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: "netconf@ietf.org" Subject: Re: [Netconf] draft-ietf-netconf-monitoring-09 last call comments from js X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Nov 2009 22:21:06 -0000 On Wed, Nov 11, 2009 at 09:44:23PM +0100, Martin Bjorklund wrote: > "Mark Scott" wrote: > > Martin, > > > > Related to the reply I posted to Juergen and Randy on this thread: > > > > By descriptive text I assume we mean only the text for each parm in sec > > 2 specifically. In which case are we effectively saying that 'see yang > > module for details' is sufficient for sec 2? > > One option is to remove section 2 and 3, and make sure all details are > moved to the YANG module. > > However, it might be nice to keep an overview, like the one in section > 2.1. Exactly. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From trac@tools.ietf.org Wed Nov 11 20:07:51 2009 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ED2FC28C1E2 for ; Wed, 11 Nov 2009 20:07:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.534 X-Spam-Level: X-Spam-Status: No, score=-102.534 tagged_above=-999 required=5 tests=[AWL=0.066, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] 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 onDI6WQYuEUv for ; Wed, 11 Nov 2009 20:07:51 -0800 (PST) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:1112:1:214:22ff:fe1f:1e54]) by core3.amsl.com (Postfix) with ESMTP id 45A5F28C1DD for ; Wed, 11 Nov 2009 20:07:51 -0800 (PST) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.69) (envelope-from ) id 1N8Qyn-0004Sx-M4; Wed, 11 Nov 2009 20:08:17 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "Netconf" X-Trac-Version: 0.11.5 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.5, by Edgewall Software To: dbharrington@comcast.net, mehmet.ersue@nsn.com X-Trac-Project: Netconf Date: Thu, 12 Nov 2009 04:08:17 -0000 X-URL: http://tools.ietf.org/wg/netconf/ X-Trac-Ticket-URL: https://svn.tools.ietf.org/wg/netconf/trac/ticket/13#comment:3 Message-ID: <078.40ac74f394ed74ff652c969077979997@tools.ietf.org> References: <069.67db73213b15a7c8a505a3140110d189@tools.ietf.org> X-Trac-Ticket-ID: 13 In-Reply-To: <069.67db73213b15a7c8a505a3140110d189@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: dbharrington@comcast.net, mehmet.ersue@nsn.com, netconf@ietf.org, netconf@ops.ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false X-Mailman-Approved-At: Wed, 11 Nov 2009 23:55:10 -0800 Cc: netconf@ietf.org, netconf@ops.ietf.org Subject: Re: [Netconf] #13: testing ML notification X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Reply-To: netconf@ops.ietf.org List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Nov 2009 04:07:52 -0000 #13: testing ML notification --------------------------------------+------------------------------------- Reporter: dbharrington@… | Owner: dbharrington@… Type: task | Status: closed Priority: trivial | Milestone: Component: notification | Version: Severity: Dead WG Document | Resolution: fixed Keywords: test | --------------------------------------+------------------------------------- Changes (by mehmet.ersue@…): * status: assigned => closed * resolution: => fixed * component: RFC4741 => notification * severity: => Dead WG Document -- Ticket URL: Netconf Issue tracker for the NETCONF Working Group From mehmet.ersue@nsn.com Thu Nov 12 01:49:45 2009 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 659AC28C0FE for ; Thu, 12 Nov 2009 01:49:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.661 X-Spam-Level: X-Spam-Status: No, score=-2.661 tagged_above=-999 required=5 tests=[AWL=-0.062, BAYES_00=-2.599] 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 j4Qf0WmcsUsh for ; Thu, 12 Nov 2009 01:49:44 -0800 (PST) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [93.183.12.32]) by core3.amsl.com (Postfix) with ESMTP id 240F93A68B9 for ; Thu, 12 Nov 2009 01:49:43 -0800 (PST) Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd001.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id nAC9oAmO011380 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 12 Nov 2009 10:50:10 +0100 Received: from demuexc024.nsn-intra.net (demuexc024.nsn-intra.net [10.159.32.11]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id nAC9o4T8028245; Thu, 12 Nov 2009 10:50:10 +0100 Received: from DEMUEXC006.nsn-intra.net ([10.150.128.18]) by demuexc024.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Thu, 12 Nov 2009 10:50:09 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 12 Nov 2009 10:50:07 +0100 Message-ID: <80A0822C5E9A4440A5117C2F4CD36A6416DB4E@DEMUEXC006.nsn-intra.net> In-Reply-To: <200911091806.nA9I69Xj004452@idle.juniper.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: W-D as SHOULD in 4741bis WAS:RE: [Netconf] additional netconf (4741bis) issues Thread-Index: AcphaWCM8//MCeBfQ8+qu0Gh6zqTwgCEsw5Q References: <4AF83F9D.70105@netconfcentral.com> <200911091806.nA9I69Xj004452@idle.juniper.net> From: "Ersue, Mehmet (NSN - DE/Munich)" To: "ext Phil Shafer" , "Andy Bierman" X-OriginalArrivalTime: 12 Nov 2009 09:50:09.0856 (UTC) FILETIME=[85B1BC00:01CA637D] Cc: netconf@ietf.org Subject: [Netconf] W-D as SHOULD in 4741bis WAS:RE: additional netconf (4741bis) issues X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Nov 2009 09:49:45 -0000 Phil, IIRC you have been on the NETCONF/NETMOD call where we decided=20 together on the use of with-defaults and David summarized the=20 discussion results as below: David Partain wrote on Friday, October 02, 2009 10:36 AM > Subject: [netmod] Information from chair phone call on 24 September > ...... >=20 > 3. The NETCONF WG to check consensus on whether 'with-defaults:' > should be a SHOULD to implement. >=20 > 4. In conjunction with the 'with-defaults:' work, the NETCONF WG > can consider adding an XML attribute in a report-all response > that tags default data as such to help NETCONF applications. > (This discussion is already underway.) Can you elaborate why you think now differently? Mehmet =20 > -----Original Message----- > From: netconf-bounces@ietf.org=20 > [mailto:netconf-bounces@ietf.org] On Behalf Of ext Phil Shafer > Sent: Monday, November 09, 2009 7:06 PM > To: Andy Bierman > Cc: netconf@ietf.org > Subject: Re: [Netconf] additional netconf (4741bis) issues >=20 > Andy Bierman writes: > >There are NETCONF implementations that don't use YANG. > >So what? >=20 > There's no requirement in NETCONF that mandates the use of YANG. >=20 > >IMO, this is a SHOULD requirement. We have already established > >that the server knows all the default leafs, even when the > >meta-data is incomplete so the client cannot deduce the values. >=20 > We have also established (by existence proof) that NETCONF servers > don't need W-D. It's a "nice to have", not something that is > a requirement, SHOULD or otherwise. >=20 > Thanks, > Phil > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf >=20 From mehmet.ersue@nsn.com Thu Nov 12 02:25:19 2009 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7FC883A6994 for ; Thu, 12 Nov 2009 02:25:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.658 X-Spam-Level: X-Spam-Status: No, score=-2.658 tagged_above=-999 required=5 tests=[AWL=-0.059, BAYES_00=-2.599] 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 bwzcou6gjmMw for ; Thu, 12 Nov 2009 02:25:18 -0800 (PST) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [93.183.12.32]) by core3.amsl.com (Postfix) with ESMTP id 3DDB53A68B3 for ; Thu, 12 Nov 2009 02:25:17 -0800 (PST) Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd001.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id nACAPi2H031148 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 12 Nov 2009 11:25:44 +0100 Received: from demuexc024.nsn-intra.net (demuexc024.nsn-intra.net [10.159.32.11]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id nACAPfad017307; Thu, 12 Nov 2009 11:25:44 +0100 Received: from DEMUEXC006.nsn-intra.net ([10.150.128.18]) by demuexc024.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Thu, 12 Nov 2009 11:25:43 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 12 Nov 2009 11:25:40 +0100 Message-ID: <80A0822C5E9A4440A5117C2F4CD36A6416DB98@DEMUEXC006.nsn-intra.net> In-Reply-To: <20091111222131.GA2218@elstar.local> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Netconf] draft-ietf-netconf-monitoring-09 last call comments from js Thread-Index: AcpjHVcL7s/fWf6+SNq6Tjy3rwk0VAAZHx4A References: <200911031432.nA3EWxSg065216@idle.juniper.net><20091103.160400.23684688.mbj@tail-f.com><085091CB2CA14E4B8B163FFC37C84E9D1AE8C736@zcarhxm0.corp.nortel.com><20091111.214423.197351074.mbj@tail-f.com> <20091111222131.GA2218@elstar.local> From: "Ersue, Mehmet (NSN - DE/Munich)" To: "Juergen Schoenwaelder" , "Martin Bjorklund" X-OriginalArrivalTime: 12 Nov 2009 10:25:43.0081 (UTC) FILETIME=[7D320990:01CA6382] Cc: netconf@ietf.org Subject: Re: [Netconf] draft-ietf-netconf-monitoring-09 last call comments from js X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Nov 2009 10:25:19 -0000 Juergen Schoenwaelder Wednesday, November 11, 2009 11:22 PM > On Wed, Nov 11, 2009 at 09:44:23PM +0100, Martin Bjorklund wrote: > > "Mark Scott" wrote: > > > Martin, > > >=20 > > > Related to the reply I posted to Juergen and Randy on this thread: > > >=20 > > > By descriptive text I assume we mean only the text for=20 > each parm in sec > > > 2 specifically. In which case are we effectively saying=20 > that 'see yang > > > module for details' is sufficient for sec 2? > >=20 > > One option is to remove section 2 and 3, and make sure all=20 > details are > > moved to the YANG module. > >=20 > > However, it might be nice to keep an overview, like the one=20 > in section > > 2.1. >=20 > Exactly. We talked in the session to have the YANG module definition complete and self-explaining first. You can have any overview, explaining text or examples in the RFC chapters. Mehmet From phil@juniper.net Thu Nov 12 06:55:38 2009 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 789783A6840 for ; Thu, 12 Nov 2009 06:55:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.549 X-Spam-Level: X-Spam-Status: No, score=-6.549 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 eDvLUho7wgIG for ; Thu, 12 Nov 2009 06:55:37 -0800 (PST) Received: from exprod7og119.obsmtp.com (exprod7og119.obsmtp.com [64.18.2.16]) by core3.amsl.com (Postfix) with ESMTP id 7F9A93A6895 for ; Thu, 12 Nov 2009 06:55:36 -0800 (PST) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob119.postini.com ([64.18.6.12]) with SMTP ID DSNKSvwiAulIQlj+pLeGx1d1DvLeON+Jm7jD@postini.com; Thu, 12 Nov 2009 06:56:07 PST Received: from p-emfe01-sac.jnpr.net (66.129.254.72) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server id 8.1.375.2; Thu, 12 Nov 2009 06:51:28 -0800 Received: from p-emlb01-sac.jnpr.net ([66.129.254.46]) by p-emfe01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Thu, 12 Nov 2009 06:51:28 -0800 Received: from emailsmtp55.jnpr.net ([172.24.18.132]) by p-emlb01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Thu, 12 Nov 2009 06:51:28 -0800 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp55.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Thu, 12 Nov 2009 06:51:27 -0800 Received: from idle.juniper.net (idleski.juniper.net [172.25.4.26]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id nACEpQj38252; Thu, 12 Nov 2009 06:51:26 -0800 (PST) (envelope-from phil@juniper.net) Received: from idle.juniper.net (localhost [127.0.0.1]) by idle.juniper.net (8.13.8/8.13.8) with ESMTP id nACEc8oo089483; Thu, 12 Nov 2009 14:38:09 GMT (envelope-from phil@idle.juniper.net) Message-ID: <200911121438.nACEc8oo089483@idle.juniper.net> To: "Ersue, Mehmet (NSN - DE/Munich)" In-Reply-To: <80A0822C5E9A4440A5117C2F4CD36A6416DB4E@DEMUEXC006.nsn-intra.net> Date: Thu, 12 Nov 2009 09:38:08 -0500 From: Phil Shafer X-OriginalArrivalTime: 12 Nov 2009 14:51:27.0309 (UTC) FILETIME=[9CB227D0:01CA63A7] MIME-Version: 1.0 Content-Type: text/plain Cc: netconf@ietf.org Subject: Re: [Netconf] W-D as SHOULD in 4741bis WAS:RE: additional netconf (4741bis) issues X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Nov 2009 14:55:38 -0000 "Ersue, Mehmet (NSN - DE/Munich)" writes: >IIRC you have been on the NETCONF/NETMOD call where we decided >together on the use of with-defaults and David summarized the >discussion results as below: >David Partain wrote on Friday, October 02, 2009 10:36 AM >> 3. The NETCONF WG to check consensus on whether 'with-defaults:' >> should be a SHOULD to implement. The bullet is "check concensus". This does not imply that the concensus of folks on the call was that this is a good idea. I have never thought it was reasonable and continue in that opinion. There is nothing in NETCONF (or YANG) that requires W-DEF and there's no reason it MUST be a SHOULD. Thanks, Phil From andy@netconfcentral.com Thu Nov 12 07:12:32 2009 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EA3143A6BDF for ; Thu, 12 Nov 2009 07:12:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[AWL=0.164, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, UNPARSEABLE_RELAY=0.001] 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 DCpwr0VvLPSX for ; Thu, 12 Nov 2009 07:12:32 -0800 (PST) Received: from smtp126.sbc.mail.sp1.yahoo.com (smtp126.sbc.mail.sp1.yahoo.com [69.147.65.185]) by core3.amsl.com (Postfix) with SMTP id 18D9D3A6AB2 for ; Thu, 12 Nov 2009 07:12:32 -0800 (PST) Received: (qmail 70033 invoked from network); 12 Nov 2009 15:12:59 -0000 Received: from adsl-67-125-158-26.dsl.irvnca.pacbell.net (andy@67.125.158.26 with plain) by smtp126.sbc.mail.sp1.yahoo.com with SMTP; 12 Nov 2009 07:12:59 -0800 PST X-Yahoo-SMTP: Z6xhxCCswBAlhcxjVNwaQtp4EKpLdTUUf5Nx_pGy81o- X-YMail-OSG: wmsUqwAVM1m9X.vFM73pHvJYpQ.vVF2ssd6Wh2MjfZSHBe1k_BjEZ2iCV7GqfXI0lHQk6.9g03sGpMhsjcrETXJZCjkst17yP.hJIQ7jk8iAXdd1minZbc4G1ZBwTvmd0_eWWNGU3b_rVcLKWPclKIIVu6koC5I1uDaHBcb4Ib8TUBnLhy4U785rW_pjHDD1QgLiFxWuZJ.DdiJ_mFZWnSW0IaU9KpETrzWyxiQCPMorSrABCbt7ADFsBx7nvJnF X-Yahoo-Newman-Property: ymail-3 Message-ID: <4AFC2613.5010405@netconfcentral.com> Date: Thu, 12 Nov 2009 07:13:23 -0800 From: Andy Bierman User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: Phil Shafer References: <200911121438.nACEc8oo089483@idle.juniper.net> In-Reply-To: <200911121438.nACEc8oo089483@idle.juniper.net> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: netconf@ietf.org Subject: Re: [Netconf] W-D as SHOULD in 4741bis WAS:RE: additional netconf (4741bis) issues X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Nov 2009 15:12:33 -0000 Phil Shafer wrote: > "Ersue, Mehmet (NSN - DE/Munich)" writes: >> IIRC you have been on the NETCONF/NETMOD call where we decided >> together on the use of with-defaults and David summarized the >> discussion results as below: >> David Partain wrote on Friday, October 02, 2009 10:36 AM >>> 3. The NETCONF WG to check consensus on whether 'with-defaults:' >>> should be a SHOULD to implement. > > The bullet is "check concensus". This does not imply that the > concensus of folks on the call was that this is a good idea. > I have never thought it was reasonable and continue in that > opinion. There is nothing in NETCONF (or YANG) that requires > W-DEF and there's no reason it MUST be a SHOULD. > There are many ways that the meta-data that is needed to derive the default (or determine that a missing leaf instance indicates no default is being used) can be incomplete. Your claim that the client can simply figure out the default that is is effect doesn't work reliably. The only reliable mechanism is to retrieve the default value that is in use on the server. The importance of using correct data instead of guessing, and perhaps using wrong data, is critical to the application developer. > Thanks, > Phil > Andy From phil@juniper.net Thu Nov 12 07:34:53 2009 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D3E033A67D7 for ; Thu, 12 Nov 2009 07:34:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.55 X-Spam-Level: X-Spam-Status: No, score=-6.55 tagged_above=-999 required=5 tests=[AWL=0.049, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 tMisBXP7z2dW for ; Thu, 12 Nov 2009 07:34:53 -0800 (PST) Received: from exprod7og102.obsmtp.com (exprod7og102.obsmtp.com [64.18.2.157]) by core3.amsl.com (Postfix) with ESMTP id 0DEB23A688A for ; Thu, 12 Nov 2009 07:34:51 -0800 (PST) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob102.postini.com ([64.18.6.12]) with SMTP ID DSNKSvwrNkJ3LBiRt9LnG6jXCkcGn2Gv9MPI@postini.com; Thu, 12 Nov 2009 07:35:22 PST Received: from p-emfe01-sac.jnpr.net (66.129.254.72) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server id 8.1.375.2; Thu, 12 Nov 2009 07:29:04 -0800 Received: from p-emlb02-sac.jnpr.net ([66.129.254.47]) by p-emfe01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Thu, 12 Nov 2009 07:29:04 -0800 Received: from emailsmtp55.jnpr.net ([172.24.18.132]) by p-emlb02-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Thu, 12 Nov 2009 07:29:03 -0800 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp55.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Thu, 12 Nov 2009 07:29:03 -0800 Received: from idle.juniper.net (idleski.juniper.net [172.25.4.26]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id nACFT2j56381; Thu, 12 Nov 2009 07:29:02 -0800 (PST) (envelope-from phil@juniper.net) Received: from idle.juniper.net (localhost [127.0.0.1]) by idle.juniper.net (8.13.8/8.13.8) with ESMTP id nACFFiJE089775; Thu, 12 Nov 2009 15:15:45 GMT (envelope-from phil@idle.juniper.net) Message-ID: <200911121515.nACFFiJE089775@idle.juniper.net> To: Andy Bierman In-Reply-To: <4AFC2613.5010405@netconfcentral.com> Date: Thu, 12 Nov 2009 10:15:44 -0500 From: Phil Shafer X-OriginalArrivalTime: 12 Nov 2009 15:29:03.0154 (UTC) FILETIME=[DD48C920:01CA63AC] MIME-Version: 1.0 Content-Type: text/plain Cc: netconf@ietf.org Subject: Re: [Netconf] W-D as SHOULD in 4741bis WAS:RE: additional netconf (4741bis) issues X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Nov 2009 15:34:53 -0000 Andy Bierman writes: >Your claim that the client can simply figure out the >default that is is effect doesn't work reliably. There are existence proofs that W-D is not needed for NETCONF apps to work reliably. In many cases, the translation between high-level config (I want to join VPN foo) and the config to perform that job (add that customer's interface to that VPN) will be completely unrelated to default values. But I'm not debating that it's useful, only that it doesn't rise to the level of a SHOULD. It's something clients and servers can live a long and happy life without needing. >The only reliable mechanism is to retrieve the >default value that is in use on the server. "in use"? Have we shifted to talking about dynamic defaults (for operational data) again? Thanks, Phil From andy@netconfcentral.com Thu Nov 12 07:57:56 2009 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D526528C1E0 for ; Thu, 12 Nov 2009 07:57:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.148 X-Spam-Level: X-Spam-Status: No, score=-2.148 tagged_above=-999 required=5 tests=[AWL=0.450, BAYES_00=-2.599, UNPARSEABLE_RELAY=0.001] 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 ntMkSOovYlXL for ; Thu, 12 Nov 2009 07:57:56 -0800 (PST) Received: from smtp103.sbc.mail.mud.yahoo.com (smtp103.sbc.mail.mud.yahoo.com [68.142.198.202]) by core3.amsl.com (Postfix) with SMTP id F26F728C1D1 for ; Thu, 12 Nov 2009 07:57:55 -0800 (PST) Received: (qmail 93167 invoked from network); 12 Nov 2009 15:58:22 -0000 Received: from adsl-67-125-158-26.dsl.irvnca.pacbell.net (andy@67.125.158.26 with plain) by smtp103.sbc.mail.mud.yahoo.com with SMTP; 12 Nov 2009 07:58:22 -0800 PST X-Yahoo-SMTP: Z6xhxCCswBAlhcxjVNwaQtp4EKpLdTUUf5Nx_pGy81o- X-YMail-OSG: 7fM3C0EVM1kwJp5pmwO4qUAiAFJFkkb0xRjm_2uhsrKInvhaomdQNycN4lF26Prc1E0sWrDQdJeVXlxcg8nnKYEikP1yyVRK.f31mkeNKy.XHtAW3wHGLRltrFSp.jFW_p6dpG4_BIodY20WplI6De3YVIXrQGm9DGVd7ZJNYA1WAaMooSPsTabdAeLM_0ZhFwA_nIfu4_UHCn2SZwL1fYM4yzChds3Kyu1KsjPYCC_OsTpa6tEqImYNDCGzWzB0 X-Yahoo-Newman-Property: ymail-3 Message-ID: <4AFC30B6.704@netconfcentral.com> Date: Thu, 12 Nov 2009 07:58:46 -0800 From: Andy Bierman User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: Phil Shafer References: <200911121515.nACFFiJE089775@idle.juniper.net> In-Reply-To: <200911121515.nACFFiJE089775@idle.juniper.net> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: netconf@ietf.org Subject: Re: [Netconf] W-D as SHOULD in 4741bis WAS:RE: additional netconf (4741bis) issues X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Nov 2009 15:57:56 -0000 Phil Shafer wrote: > Andy Bierman writes: >> Your claim that the client can simply figure out the >> default that is is effect doesn't work reliably. > > There are existence proofs that W-D is not needed for NETCONF apps > to work reliably. In many cases, the translation between high-level > config (I want to join VPN foo) and the config to perform that job > (add that customer's interface to that VPN) will be completely > unrelated to default values. > The IETF members have every right to focus on the interoperability needs of the IETF. Unless the import/include by revision is used in every case, and every module has a revision, and every module is advertised, then the client cannot deduce the defaults correctly. There does not seem to be any consensus to require YANG writers to follow these strict rules. Since the revision-date has not been used in any YANG data model so far, it seems unlikely these rules would be followed anyway. > But I'm not debating that it's useful, only that it doesn't rise > to the level of a SHOULD. It's something clients and servers can > live a long and happy life without needing. > Some people think the client MUST be able to retrieve all values that affect the device. There seem to be even more who think all values SHOULD be retrievable. >> The only reliable mechanism is to retrieve the >> default value that is in use on the server. > > "in use"? Have we shifted to talking about dynamic defaults (for > operational data) again? > No -- the server 'knows' exactly what it implements. The client may have to guess what the server knows, unless the 'report-all' option is available for retrieval. If the server uses only modules with revision dates, and every import/include has a revision date, and every module is advertised in the , then W-D is just a nice-to-have. Otherwise, it is a SHOULD have. > Thanks, > Phil > Andy From phil@juniper.net Thu Nov 12 11:38:06 2009 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 75ACE3A6B1C for ; Thu, 12 Nov 2009 11:38:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.551 X-Spam-Level: X-Spam-Status: No, score=-6.551 tagged_above=-999 required=5 tests=[AWL=0.048, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 NtKhaK6xbmHp for ; Thu, 12 Nov 2009 11:38:05 -0800 (PST) Received: from exprod7og127.obsmtp.com (exprod7og127.obsmtp.com [64.18.2.210]) by core3.amsl.com (Postfix) with ESMTP id E10C03A6B1B for ; Thu, 12 Nov 2009 11:38:04 -0800 (PST) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob127.postini.com ([64.18.6.12]) with SMTP ID DSNKSvxkN9xTw0DX896sltyOgiuka+CEw5sG@postini.com; Thu, 12 Nov 2009 11:38:35 PST Received: from p-emfe01-sac.jnpr.net (66.129.254.72) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server id 8.1.375.2; Thu, 12 Nov 2009 11:34:09 -0800 Received: from p-emlb01-sac.jnpr.net ([66.129.254.46]) by p-emfe01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Thu, 12 Nov 2009 11:34:09 -0800 Received: from emailsmtp56.jnpr.net ([172.24.60.77]) by p-emlb01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Thu, 12 Nov 2009 11:34:08 -0800 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp56.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Thu, 12 Nov 2009 11:34:07 -0800 Received: from idle.juniper.net (idleski.juniper.net [172.25.4.26]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id nACJY7j81533; Thu, 12 Nov 2009 11:34:07 -0800 (PST) (envelope-from phil@juniper.net) Received: from idle.juniper.net (localhost [127.0.0.1]) by idle.juniper.net (8.13.8/8.13.8) with ESMTP id nACJKmDR091948; Thu, 12 Nov 2009 19:20:48 GMT (envelope-from phil@idle.juniper.net) Message-ID: <200911121920.nACJKmDR091948@idle.juniper.net> To: Andy Bierman In-Reply-To: <4AFC30B6.704@netconfcentral.com> Date: Thu, 12 Nov 2009 14:20:48 -0500 From: Phil Shafer X-OriginalArrivalTime: 12 Nov 2009 19:34:07.0863 (UTC) FILETIME=[19F95070:01CA63CF] MIME-Version: 1.0 Content-Type: text/plain Cc: netconf@ietf.org Subject: Re: [Netconf] W-D as SHOULD in 4741bis WAS:RE: additional netconf (4741bis) issues X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Nov 2009 19:38:06 -0000 Andy Bierman writes: >The IETF members have every right to focus on >the interoperability needs of the IETF. Is this an issue for your guidelines document then? It's certainly not needed in the base NETCONF spec. Thanks, Phil From MARKSCOT@nortel.com Thu Nov 12 13:02:16 2009 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8D7B43A68AA for ; Thu, 12 Nov 2009 13:02:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 GrW8O9WBtWKp for ; Thu, 12 Nov 2009 13:02:15 -0800 (PST) Received: from zrtps0kp.nortel.com (zrtps0kp.nortel.com [47.140.192.56]) by core3.amsl.com (Postfix) with ESMTP id 804FF3A6801 for ; Thu, 12 Nov 2009 13:02:15 -0800 (PST) Received: from zcarhxm0.corp.nortel.com (zcarhxm0.corp.nortel.com [47.129.230.95]) by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id nACL2XY08334; Thu, 12 Nov 2009 21:02:33 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 12 Nov 2009 16:01:45 -0500 Message-ID: <085091CB2CA14E4B8B163FFC37C84E9D1AED8656@zcarhxm0.corp.nortel.com> In-Reply-To: <80A0822C5E9A4440A5117C2F4CD36A6416DB98@DEMUEXC006.nsn-intra.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Netconf] draft-ietf-netconf-monitoring-09 last call commentsfrom js Thread-Index: AcpjHVcL7s/fWf6+SNq6Tjy3rwk0VAAZHx4AABZbAuA= References: <200911031432.nA3EWxSg065216@idle.juniper.net><20091103.160400.23684688.mbj@tail-f.com><085091CB2CA14E4B8B163FFC37C84E9D1AE8C736@zcarhxm0.corp.nortel.com><20091111.214423.197351074.mbj@tail-f.com><20091111222131.GA2218@elstar.local> <80A0822C5E9A4440A5117C2F4CD36A6416DB98@DEMUEXC006.nsn-intra.net> From: "Mark Scott" To: "Ersue, Mehmet (NSN - DE/Munich)" , "Juergen Schoenwaelder" , "Martin Bjorklund" Cc: netconf@ietf.org Subject: Re: [Netconf] draft-ietf-netconf-monitoring-09 last call commentsfrom js X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Nov 2009 21:02:16 -0000 The content will be moved into the YANG module in the next version. Mark -----Original Message----- From: netconf-bounces@ietf.org [mailto:netconf-bounces@ietf.org] On Behalf Of Ersue, Mehmet (NSN - DE/Munich) Sent: Thursday, November 12, 2009 5:26 AM To: Juergen Schoenwaelder; Martin Bjorklund Cc: netconf@ietf.org Subject: Re: [Netconf] draft-ietf-netconf-monitoring-09 last call commentsfrom js Juergen Schoenwaelder Wednesday, November 11, 2009 11:22 PM > On Wed, Nov 11, 2009 at 09:44:23PM +0100, Martin Bjorklund wrote: > > "Mark Scott" wrote: > > > Martin, > > >=20 > > > Related to the reply I posted to Juergen and Randy on this thread: > > >=20 > > > By descriptive text I assume we mean only the text for=20 > each parm in sec > > > 2 specifically. In which case are we effectively saying=20 > that 'see yang > > > module for details' is sufficient for sec 2? > >=20 > > One option is to remove section 2 and 3, and make sure all=20 > details are > > moved to the YANG module. > >=20 > > However, it might be nice to keep an overview, like the one=20 > in section > > 2.1. >=20 > Exactly. We talked in the session to have the YANG module definition complete and self-explaining first. You can have any overview, explaining text or examples in the RFC chapters. Mehmet _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From MARKSCOT@nortel.com Fri Nov 13 05:17:14 2009 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4012B3A6A5E for ; Fri, 13 Nov 2009 05:17:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] 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 YDhjFg9yc8oQ for ; Fri, 13 Nov 2009 05:17:12 -0800 (PST) Received: from zrtps0kp.nortel.com (zrtps0kp.nortel.com [47.140.192.56]) by core3.amsl.com (Postfix) with ESMTP id EAD333A6A73 for ; Fri, 13 Nov 2009 05:17:11 -0800 (PST) Received: from zcarhxm0.corp.nortel.com (zcarhxm0.corp.nortel.com [47.129.230.95]) by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id nADDHZ526029; Fri, 13 Nov 2009 13:17:35 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CA6463.A523EE24" Date: Fri, 13 Nov 2009 08:17:23 -0500 Message-ID: <085091CB2CA14E4B8B163FFC37C84E9D1AED8989@zcarhxm0.corp.nortel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: update for 4741bis (text removed from monitoring draft) Thread-Index: AcpkY6MtQUExm7A8S5+HYCKNcOuQjg== From: "Mark Scott" To: "Martin Bjorklund" Cc: netconf@ietf.org Subject: [Netconf] update for 4741bis (text removed from monitoring draft) X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Nov 2009 13:17:14 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CA6463.A523EE24 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Martin, =20 Per ML consensus the following text has been removed from the monitoring draft and should be covered in 4741bis (if not already sufficiently covered there): =20 "The capabilities of a NETCONF server may change over time. However, once a NETCONF server has announced its capabilities in the message, the capabilities for that session MUST NOT change. A server MUST reply with a 'capabilities-changed' error if the client sends a request which is affected by a modified capability. =20 A server MAY choose to send 'capabilities-changed' as the response to any request other than if its capabilities has changed." =20 It will be removed from the monitoring draft in rev-10. =20 cheers, Mark ------_=_NextPart_001_01CA6463.A523EE24 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Martin,

 

Per ML consensus the following text has been = removed from the monitoring draft and should be covered in 4741bis (if not already = sufficiently covered there):

 

         &= nbsp;      “The capabilities of a NETCONF server may change over time.  = However,

         &= nbsp;      once a NETCONF server has announced its capabilities in the = <hello>

        =         message, the capabilities for that session MUST NOT change.  = A

         &= nbsp;      server MUST reply with a 'capabilities-changed' error if the = client

         &= nbsp;      sends a request which is affected by a modified capability.

 

         &= nbsp;      A server MAY choose to send 'capabilities-changed' as the = response

         &= nbsp;      to any request other than <close-session> if its capabilities = has

         &= nbsp;      changed.”

 

It will be removed from the monitoring draft in = rev-10.

 

cheers,

Mark

------_=_NextPart_001_01CA6463.A523EE24-- From andy@netconfcentral.com Fri Nov 13 08:55:49 2009 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7DE0B3A6A2D for ; Fri, 13 Nov 2009 08:55:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.107 X-Spam-Level: X-Spam-Status: No, score=-2.107 tagged_above=-999 required=5 tests=[AWL=0.157, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, UNPARSEABLE_RELAY=0.001] 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 8GsB8682qnow for ; Fri, 13 Nov 2009 08:55:48 -0800 (PST) Received: from smtp125.sbc.mail.sp1.yahoo.com (smtp125.sbc.mail.sp1.yahoo.com [69.147.65.184]) by core3.amsl.com (Postfix) with SMTP id D8BF73A687C for ; Fri, 13 Nov 2009 08:55:48 -0800 (PST) Received: (qmail 28824 invoked from network); 13 Nov 2009 16:56:16 -0000 Received: from adsl-67-125-158-26.dsl.irvnca.pacbell.net (andy@67.125.158.26 with plain) by smtp125.sbc.mail.sp1.yahoo.com with SMTP; 13 Nov 2009 08:56:16 -0800 PST X-Yahoo-SMTP: Z6xhxCCswBAlhcxjVNwaQtp4EKpLdTUUf5Nx_pGy81o- X-YMail-OSG: va945ZkVM1m7IJwtxV6un35crQaq15Jrmmyn_AUx.4LJRucV.nxBVIbmh72KkihD3NxfEDigLSqSDNf01Q8XY7R3IS.x7r.L1PCpeX1qCksRFlORsAT52pOTFSctrnFbns2TFd8M078.DFPjv5NJcOYdVsgGBl8ZkKGJu3qLdkyxOo0c9Yfleem6ohlrvGRiRko6Iw2HTMhFyJl0biFFvh7ltR7y.PPRiKbx7Pt8Zi0mX6vAU.A2A8CH1gpK4rMhPNR6SwZUP6L0Js_4.XDISXwljp5VXjq0O2sw0nGQVMuUjarNvW4_rkE5gZWIzR7xR8uj7P2BPPSv4TIHXqPGUOODON3uTOgQckXElDYvRQsX5pSqDh9NgFMWJ7Upzuhi X-Yahoo-Newman-Property: ymail-3 Message-ID: <4AFD8F58.1000904@netconfcentral.com> Date: Fri, 13 Nov 2009 08:54:48 -0800 From: Andy Bierman User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: NETCONF Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [Netconf] error-path issues X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Nov 2009 16:55:49 -0000 Hi, I opened a new trouble ticket for 4741bis: http://trac.tools.ietf.org/wg/netconf/trac/ticket/20 There may be 2 issues related to error-path 1) error-path SHOULD be used whenever possible, and error-info/bad-element SHOULD NOT be used [this ticket] I plan to address this issue in the next 4741bis draft by adding normative text similar to the text above. The XSD will not be changed (minOccurs=0 will still be present because this is a SHOULD, not a MUST). 2) error-path will be with /nc:rpc if the error-causing data is within the request PDU. It will start with the top-level database element if the data is not within the request PDU (e.g., commit, copy-config, validate). [no ticket] I am not sure if this issue is already resolved. The YANG draft specifies this behavior but 4741bis has contradictory text. Andy From mehmet.ersue@nsn.com Fri Nov 20 10:32:45 2009 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 281C73A67AA; Fri, 20 Nov 2009 10:32:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.299 X-Spam-Level: X-Spam-Status: No, score=-1.299 tagged_above=-999 required=5 tests=[AWL=1.299, BAYES_00=-2.599, HTML_MESSAGE=0.001] 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 GRyaUZK8tkFi; Fri, 20 Nov 2009 10:32:43 -0800 (PST) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [93.183.12.32]) by core3.amsl.com (Postfix) with ESMTP id 832D53A6961; Fri, 20 Nov 2009 10:32:42 -0800 (PST) Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd001.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id nAKIWXrK019581 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 20 Nov 2009 19:32:33 +0100 Received: from demuexc022.nsn-intra.net (demuexc022.nsn-intra.net [10.150.128.35]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id nAKIWVjY029641; Fri, 20 Nov 2009 19:32:33 +0100 Received: from DEMUEXC006.nsn-intra.net ([10.150.128.103]) by demuexc022.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Fri, 20 Nov 2009 19:32:31 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----_=_NextPart_001_01CA6A0F.D1FCD315" Date: Fri, 20 Nov 2009 19:32:30 +0100 Message-ID: <80A0822C5E9A4440A5117C2F4CD36A641A0C02@DEMUEXC006.nsn-intra.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Consensus call: With-Defaults as SHOULD in 4741bis Thread-Index: AcpqD9EtAgyl1/HvS2qsgWLqs7N6kg== From: "Ersue, Mehmet (NSN - DE/Munich)" To: , "NETMOD Working Group" X-OriginalArrivalTime: 20 Nov 2009 18:32:31.0726 (UTC) FILETIME=[D23590E0:01CA6A0F] Cc: David Partain , "Kessens, David \(NSN - US/Atlanta\)" Subject: [Netconf] Consensus call: With-Defaults as SHOULD in 4741bis X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Nov 2009 18:32:45 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CA6A0F.D1FCD315 Content-Type: multipart/alternative; boundary="----_=_NextPart_002_01CA6A0F.D1FCD315" ------_=_NextPart_002_01CA6A0F.D1FCD315 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Hi All, in the NETCONF/NETMOD conference call we discussed the=20 handling of with-defaults in 4741bis document and the=20 YANG specification. We had a rough consensus on having 'with-defaults' as=20 SHOULD to implement (see point 3 in the attached mail=20 from October 02, 2009), which is going to be added to=20 the 4741bis document if we have consensus. We do not want to go through a re-run of all arguments=20 for and against. Since this conclusion has an impact=20 on both NETCONF 4741bis and the YANG specifications=20 the co-chairs of NETCONF and NETMOD WGs are keen of=20 having a final consensus call on that.=20 All on NETCONF and NETMOD WG maillists, please read=20 the attached mail of David Partain and respond to this=20 mail by December 1, 2009 EOB PT. <<[netmod] Information from chair phone call on 24 September>>=20 If you agree with the conclusion having 'with-defaults'=20 as SHOULD to implement in 4741bis please state so. If you disagree with this consensus, state your opinion too. Thank you. Bert & Mehmet ------_=_NextPart_002_01CA6A0F.D1FCD315 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Consensus call: With-Defaults as SHOULD in 4741bis

Hi All,

in the NETCONF/NETMOD conference = call we discussed the
handling of with-defaults in = 4741bis document and the
YANG specification.

We had a rough consensus on = having 'with-defaults' as
SHOULD to implement (see point 3 = in the attached mail
from October 02, 2009), which is = going to be added to
the 4741bis document if we have = consensus.

We do not want to go through a = re-run of all arguments
for and against. Since this = conclusion has an impact
on both NETCONF 4741bis and the = YANG specifications
the co-chairs of NETCONF and = NETMOD WGs are keen of
having a final consensus call on = that.

All on NETCONF and NETMOD WG = maillists, please read
the attached mail of David = Partain and respond to this
mail by December 1, 2009 EOB = PT.
<<[netmod] = Information from chair phone call on 24 September>>

If you agree with the conclusion = having 'with-defaults'
as SHOULD to implement in = 4741bis please state so.
If you disagree with this = consensus, state your opinion too.

Thank you.

Bert & Mehmet

------_=_NextPart_002_01CA6A0F.D1FCD315-- ------_=_NextPart_001_01CA6A0F.D1FCD315 Content-Type: message/rfc822 Content-Transfer-Encoding: 7bit X-MimeOLE: Produced By Microsoft Exchange V6.5 Received: from demuexc023.nsn-intra.net ([10.150.128.36]) by DEMUEXC005.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Fri, 2 Oct 2009 10:37:12 +0200 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_003_01CA433B.895A2C00" Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demuexc023.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Fri, 2 Oct 2009 10:37:12 +0200 Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [217.115.75.233]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id n928bCP1010039 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 2 Oct 2009 10:37:12 +0200 Received: from mail.ietf.org (mail.ietf.org [64.170.98.32]) by demumfd001.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id n928bBra002326; Fri, 2 Oct 2009 10:37:11 +0200 Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 56C7F3A68E2; Fri, 2 Oct 2009 01:35:42 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7222B3A68BB; Fri, 2 Oct 2009 01:35:41 -0700 (PDT) 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 CfkZsIyilLfb; Fri, 2 Oct 2009 01:35:40 -0700 (PDT) Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by core3.amsl.com (Postfix) with ESMTP id C8C273A67F2; Fri, 2 Oct 2009 01:35:39 -0700 (PDT) Received: from esealmw128.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw3.ericsson.se (Symantec Mail Security) with SMTP id 1F.2C.15624.1BBB5CA4; Fri, 2 Oct 2009 10:37:05 +0200 (CEST) Received: from esealmw128.eemea.ericsson.se ([153.88.254.176]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Fri, 2 Oct 2009 10:36:20 +0200 Received: from selic023.lmera.ericsson.se ([150.132.89.214]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Fri, 2 Oct 2009 10:36:20 +0200 Content-class: urn:content-classes:message Subject: [netmod] Information from chair phone call on 24 September Date: Fri, 2 Oct 2009 09:36:19 +0100 Message-ID: <200910021036.19330.david.partain@ericsson.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [netmod] Information from chair phone call on 24 September Thread-Index: AcpDO4oagOlA/vfaRLmpSofowILzNg== List-Help: List-Subscribe: , List-Unsubscribe: , From: "ext David Partain" Sender: To: , "NETMOD Working Group" This is a multi-part message in MIME format. ------_=_NextPart_003_01CA433B.895A2C00 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, This mail summarizes the conversation that the 4 co-chairs of NETCONF/NETMOD had with interested parties on default issue. This mail is NOT intended to re-open the question about default handling but to confirm that what we believe is a reasonable way forward is a decision that the working groups can live with. Silence will be considered consent! 1. There were a number of comments during the call that indicated that we need text that says that defaults are taken into consideration in validation. 2. The defaults question: No fundamental changes to the model are needed. That is, a server MAY choose not to send back values that are the default as defined in the YANG model. Instead, we are going to try to address some things that will tighten up potential inconsistencies (to "SHOULD level", not "MUST level") in dealing with defaults. There are cases where you don't necessarily know what a non-answer about an object with a default clause means. In particular, this means looking at upgrade rules, dealing with leafrefs and instance-identifiers. We should try to address the most common cases without trying to cover all possible corner cases. We need specific text, which Andy and Martin have been asked to address. Again, we are not re-opening this discussion by sending this mail: we wish to confirm that this is the right way forward. Some expressed a wish that there be a simple, short explanation of how defaults are handled in general so that one doesn't need to be privy of the entire YANG history to understand why things are the way they are. If you believe that this is useful, please offer text or, at a minimum, point out where you think text is missing. 3. The NETCONF WG to check consensus on whether 'with-defaults:' should be a SHOULD to implement. 4. In conjunction with the 'with-defaults:' work, the NETCONF WG can consider adding an XML attribute in a report-all response that tags default data as such to help NETCONF applications. (This discussion is already underway.) 5. Juergen agreed to help with some examples of XPath expressions refering to config / non-config / garbage data. (I think I got this right.) If others believe that other examples are needed, please suggest that on the mailing list. 6. We need to start thinking about (and writing about) the issue of config vs. statistics vs. operational data. This is something that needs to be given serious thought and energy. This will be done separately (and after) the YANG work is complete. 7. We will try to put text in the architecture draft as a sort of "placeholder" with respect to #5. Text has been suggested on the mailing list before and that should be put into the draft. Thanks. David _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod ------_=_NextPart_003_01CA433B.895A2C00 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable [netmod] Information from chair phone call on 24 = September

Hi,

This mail summarizes the conversation that the 4 = co-chairs of
NETCONF/NETMOD had with interested parties on default = issue.
This mail is NOT intended to re-open the question = about default
handling but to confirm that what we believe is a = reasonable way
forward is a decision that the working groups can = live with.
Silence will be considered consent!

1. There were a number of comments during the call = that indicated
that we need text that says that defaults are taken = into
consideration in validation.

2.  The defaults question: No fundamental changes = to the model
are needed.  That is, a server MAY choose not to = send back values
that are the default as defined in the YANG = model.  Instead, we
are going to try to address some things that will = tighten up
potential inconsistencies (to "SHOULD = level", not "MUST level")
in dealing with defaults.  There are cases where = you don't
necessarily know what a non-answer about an object = with a default
clause means.  In particular, this means looking = at upgrade
rules, dealing with leafrefs and = instance-identifiers.  We should
try to address the most common cases without trying = to cover all
possible corner cases. We need specific text, which = Andy and
Martin have been asked to address.

Again, we are not re-opening this discussion by = sending this
mail: we wish to confirm that this is the right way = forward.

Some expressed a wish that there be a simple, short = explanation
of how defaults are handled in general so that one = doesn't need
to be privy of the entire YANG history to understand = why things
are the way they are.  If you believe that this = is useful, please
offer text or, at a minimum, point out where you = think text is
missing.

3. The NETCONF WG to check consensus on whether = 'with-defaults:'
should be a SHOULD to implement.

4. In conjunction with the 'with-defaults:' work, the = NETCONF WG
can consider adding an XML attribute in a report-all = response
that tags default data as such to help NETCONF = applications.
(This discussion is already underway.)

5. Juergen agreed to help with some examples of XPath = expressions
refering to config / non-config / garbage data.  = (I think I got
this right.)  If others believe that other = examples are needed,
please suggest that on the mailing list.

6. We need to start thinking about (and writing about) = the issue
of config vs. statistics vs. operational data.  = This is something
that needs to be given serious thought and = energy.  This will be
done separately (and after) the YANG work is = complete.

7. We will try to put text in the architecture draft = as a sort of
"placeholder" with respect to #5.  = Text has been suggested on the
mailing list before and that should be put into the = draft.

Thanks.

David

_______________________________________________
netmod mailing list
netmod@ietf.org
https://www.ietf.or= g/mailman/listinfo/netmod

------_=_NextPart_003_01CA433B.895A2C00-- ------_=_NextPart_001_01CA6A0F.D1FCD315-- From phil@juniper.net Fri Nov 20 10:59:53 2009 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E01433A6821; Fri, 20 Nov 2009 10:59:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 5LFbDCCpENf4; Fri, 20 Nov 2009 10:59:53 -0800 (PST) Received: from exprod7og122.obsmtp.com (exprod7og122.obsmtp.com [64.18.2.22]) by core3.amsl.com (Postfix) with ESMTP id E4C1D3A66B4; Fri, 20 Nov 2009 10:59:52 -0800 (PST) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob122.postini.com ([64.18.6.12]) with SMTP ID DSNKSwbnI7FnLgLoGhQIeMT2V2GEFI8vt9xR@postini.com; Fri, 20 Nov 2009 10:59:50 PST Received: from p-emfe01-sac.jnpr.net (66.129.254.72) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server id 8.1.393.1; Fri, 20 Nov 2009 10:53:37 -0800 Received: from p-emlb02-sac.jnpr.net ([66.129.254.47]) by p-emfe01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Fri, 20 Nov 2009 10:53:37 -0800 Received: from emailsmtp55.jnpr.net ([172.24.18.132]) by p-emlb02-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Fri, 20 Nov 2009 10:53:36 -0800 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp55.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Fri, 20 Nov 2009 10:53:36 -0800 Received: from idle.juniper.net (idleski.juniper.net [172.25.4.26]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id nAKIrZj59609; Fri, 20 Nov 2009 10:53:35 -0800 (PST) (envelope-from phil@juniper.net) Received: from idle.juniper.net (localhost [127.0.0.1]) by idle.juniper.net (8.13.8/8.13.8) with ESMTP id nAKIeAo9087472; Fri, 20 Nov 2009 18:40:10 GMT (envelope-from phil@idle.juniper.net) Message-ID: <200911201840.nAKIeAo9087472@idle.juniper.net> To: "Ersue, Mehmet (NSN - DE/Munich)" In-Reply-To: <80A0822C5E9A4440A5117C2F4CD36A641A0C02@DEMUEXC006.nsn-intra.net> Date: Fri, 20 Nov 2009 13:40:09 -0500 From: Phil Shafer X-OriginalArrivalTime: 20 Nov 2009 18:53:36.0391 (UTC) FILETIME=[C4022170:01CA6A12] MIME-Version: 1.0 Content-Type: text/plain Cc: David Partain , netconf@ietf.org, NETMOD Working Group , "Kessens, David \(NSN - US/Atlanta\)" Subject: Re: [Netconf] Consensus call: With-Defaults as SHOULD in 4741bis X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Nov 2009 18:59:54 -0000 "Ersue, Mehmet (NSN - DE/Munich)" writes: >We had a rough consensus on having 'with-defaults' as >SHOULD to implement (see point 3 in the attached mail >from October 02, 2009), which is going to be added to >the 4741bis document if we have consensus. As previously pointed out, the conf call's concensus was to ask the NETCONF mailing list about w-d, not that it was a SHOULD. >If you agree with the conclusion having 'with-defaults' >as SHOULD to implement in 4741bis please state so. >If you disagree with this consensus, state your opinion too. I do not want W-D to be a SHOULD requirement since it is not required for the proper operation of a NETCONF server. We have managed without it for a long long time and I do not see it as vital. Heck, there's no requirement in NETCONF for the data model to even _have_ default values. 4741 current says nothing about the data model's contents and says absolutely nothing about default values. I don't see a convincing reason why this should change. Thanks, Phil From randy_presuhn@mindspring.com Fri Nov 20 11:22:16 2009 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CAC383A6843 for ; Fri, 20 Nov 2009 11:22:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.74 X-Spam-Level: X-Spam-Status: No, score=-0.74 tagged_above=-999 required=5 tests=[BAYES_20=-0.74] 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 CikKDgtWaVDP for ; Fri, 20 Nov 2009 11:22:16 -0800 (PST) Received: from elasmtp-masked.atl.sa.earthlink.net (elasmtp-masked.atl.sa.earthlink.net [209.86.89.68]) by core3.amsl.com (Postfix) with ESMTP id E7C343A699F for ; Fri, 20 Nov 2009 11:22:08 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=DFpU3Z932z/tEZ/pWiECuNl86hdUZjdt0grBNMwCGukJaSkEoj/g8vPjCU6nl8I+; h=Received:Message-ID:From:To:References:Subject:Date:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Priority:X-MSMail-Priority:X-Mailer:X-MimeOLE:X-ELNK-Trace:X-Originating-IP; Received: from [99.41.49.99] (helo=oemcomputer) by elasmtp-masked.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1NBZ3V-0005Jh-22 for netconf@ietf.org; Fri, 20 Nov 2009 14:22:05 -0500 Message-ID: <001b01ca6a16$dca05400$6801a8c0@oemcomputer> From: "Randy Presuhn" To: References: <200911201840.nAKIeAo9087472@idle.juniper.net> Date: Fri, 20 Nov 2009 11:22:53 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-ELNK-Trace: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d8881afdcb5313ff34f9c0e8ec66f16d578e19668c837470d776350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 99.41.49.99 Subject: Re: [Netconf] Consensus call: With-Defaults as SHOULD in 4741bis X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Nov 2009 19:22:16 -0000 Hi - > From: "Phil Shafer" > To: "Ersue, Mehmet (NSN - DE/Munich)" > Cc: "David Partain" ; ; "NETMOD Working Group" ; "Kessens, David (NSN - US/Atlanta)" > Sent: Friday, November 20, 2009 10:40 AM > Subject: Re: [Netconf] Consensus call: With-Defaults as SHOULD in 4741bis ... > I do not want W-D to be a SHOULD requirement since it is not required > for the proper operation of a NETCONF server. If somethine is "required for ... proper operation" then the correct keyword is MUST, not SHOULD. See (1) in RFC 2119. > We have managed > without it for a long long time and I do not see it as vital. Heck, > there's no requirement in NETCONF for the data model to even _have_ > default values. 4741 current says nothing about the data model's > contents and says absolutely nothing about default values. I don't > see a convincing reason why this should change. RFC 2119 says "3. SHOULD This word, or the adjective "RECOMMENDED", mean that there may exist valid reasons in particular circumstances to ignore a particular item, but the full implications must be understood and carefully weighed before choosing a different course." It seems to me that "SHOULD" is indeed the correct keyword for this case. I can't see aother way of applying RFC 2119 here. Randy From mehmet.ersue@nsn.com Sun Nov 22 09:13:26 2009 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ED4B43A69A8 for ; Sun, 22 Nov 2009 09:13:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.948 X-Spam-Level: X-Spam-Status: No, score=-1.948 tagged_above=-999 required=5 tests=[AWL=0.650, BAYES_00=-2.599, HTML_MESSAGE=0.001] 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 lt-ngQq7t1Wg for ; Sun, 22 Nov 2009 09:13:25 -0800 (PST) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [93.183.12.31]) by core3.amsl.com (Postfix) with ESMTP id 6CE703A69E2 for ; Sun, 22 Nov 2009 09:13:23 -0800 (PST) Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id nAMHDBwX000921 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Sun, 22 Nov 2009 18:13:11 +0100 Received: from demuexc024.nsn-intra.net (demuexc024.nsn-intra.net [10.159.32.11]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id nAMHDBAa023514; Sun, 22 Nov 2009 18:13:11 +0100 Received: from DEMUEXC006.nsn-intra.net ([10.150.128.103]) by demuexc024.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Sun, 22 Nov 2009 18:13:11 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----_=_NextPart_001_01CA6B97.118AB635" Date: Sun, 22 Nov 2009 18:13:09 +0100 Message-ID: <80A0822C5E9A4440A5117C2F4CD36A641A0CCB@DEMUEXC006.nsn-intra.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: IETF #76 NETCONF WG Session Draft minutes Thread-Index: AcprlxC720JW2T16SA6xK6qgAsNwiQ== From: "Ersue, Mehmet (NSN - DE/Munich)" To: X-OriginalArrivalTime: 22 Nov 2009 17:13:11.0207 (UTC) FILETIME=[118B8370:01CA6B97] Subject: [Netconf] IETF #76 NETCONF WG Session Draft minutes X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Nov 2009 17:13:27 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CA6B97.118AB635 Content-Type: multipart/alternative; boundary="----_=_NextPart_002_01CA6B97.118AB635" ------_=_NextPart_002_01CA6B97.118AB635 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Dear NETCONF WG,=20 attached are the draft minutes for the NETCONF session=20 at IETF #76.=20 Many thanks to Lada and Wes for taking the minutes and=20 Dan for scribing and channeling the jabber room!=20 Please review the draft minutes and let us know your=20 comments by November 30, 2009 EOB. Thanks.=20 <<091122_IETF76_NETCONF WG_Draft_Minutes.txt>>=20 Mehmet & Bert=20 ------_=_NextPart_002_01CA6B97.118AB635 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable IETF #76 NETCONF WG Session Draft minutes

Dear NETCONF WG,

attached are the draft minutes for = the NETCONF session
at IETF #76.

Many thanks to Lada and Wes for = taking the minutes and
Dan for scribing and channeling the = jabber room!

Please review the draft minutes and = let us know your
comments by November 30, 2009 EOB. = Thanks.

= <<091122_IETF76_NETCONF WG_Draft_Minutes.txt>>
Mehmet & Bert

------_=_NextPart_002_01CA6B97.118AB635-- ------_=_NextPart_001_01CA6B97.118AB635 Content-Type: text/plain; name="091122_IETF76_NETCONF WG_Draft_Minutes.txt" Content-Transfer-Encoding: base64 Content-Description: 091122_IETF76_NETCONF WG_Draft_Minutes.txt Content-Disposition: attachment; filename="091122_IETF76_NETCONF WG_Draft_Minutes.txt" LSBEcmFmdCAtDQoNCk1pbnV0ZXMgb2YgdGhlIE5FVENPTkYgV0cgc2Vzc2lvbiwgTm92ZW1iZXIg OSwgMjAwOQ0KPT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09DQoNCkNv LUNoYWlyczogQmVydCBXaWpuZW4sIE1laG1ldCBFcnN1ZQ0KQUQ6IERhbiBSb21hc2NhbnUNCg0K TWludXRlIHRha2VyczogTGFkYSBMaG90a2EsIFdlcyBIYXJkYWtlcg0KSmFiYmVyIHNjcmliZTog RGFuIFJvbWFzY2FudQ0KDQoNClRoZSBzZXNzaW9uIHN0YXJ0ZWQgYXQgMTU6MjUsIGJsdWUgc2hl ZXRzIHdlcmUgY2lyY3VsYXRlZC4NCkFnZW5kYSBiYXNoaW5nIC0gbm8gb2JqZWN0aW9ucy9hZGRp dGlvbnMuDQoNCiogV0cgU3RhdHVzIChNZWhtZXQgRXJzdWUpDQotIHBhcnRpYWwgbG9jayBkcmFm dCBub3cgaW4gUkZDIGVkaXRvciBxdWV1ZQ0KLSBtb25pdG9yaW5nIGRyYWZ0OiBXR0xDIGVuZGVk IG9uIDIgTm92ZW1iZXINCi0gUkZDIDQ3NDFiaXMgc3RpbGwgdW5kZXIgaW50ZW5zaXZlIGRpc2N1 c3Npb24sIGlzc3VlcyByZWNvcmRlZCBpbiB0aGUgdHJhY2tlciBhcmUgYmVpbmcgcmVzb2x2ZWQN Ci0gd2l0aC1kZWZhdXRzOiBtYXkgYmUgcmVhZHkgZm9yIEFEIHJldmlldw0KDQoqIFdHIHN0YXR1 cyBvbiBub3QteWV0LWNoYXJ0ZXJlZCAoTWVobWV0KToNCi0gUkZDIDQ3NDJiaXM6IHNvbWUgZXJy YXRhIGhhdmUgYmVlbiBjb2xsZWN0ZWQsIGVkaXRvcnMgc29saWNpdGVkDQotIFJvYnVzdCBjb25m aWcgbWFuYWdlbWVudDogdGhlIGRyYWZ0IGhhc24ndCBiZWVuIHVwZGF0ZWQNCiAgLSBEYW4gUm9t YXNjYW51OiBUaGVyZSB3YXMgc29tZSBkaXNjdXNzaW9uIGFib3V0IHRoZSBkcmFmdCB3aXRoIGlu cHV0IGZyb20gTWFydGluIGFuZCBQaGlsLCBwcm90b3R5cGluZyB3b3JrIGhhcyBzdGFydGVkOyB0 aGUgYXV0aG9ycyB3aWxsIGNvbnRpbnVlIGFuZCBwcmVwYXJlIG5ldyB2ZXJzaW9uIGZvciBjb25z aWRlcmF0aW9uLg0KDQoqIE1vbml0b3JpbmcgU2NoZW1lIChCYWxhenMgcHJlc2VudGluZyBmb3Ig TWFyayBTY290dCkNCiAgLSBSZXZpc2lvbiAtMTAgcGxhbm5lZCBmb3IgZW5kIE5vdmVtYmVyDQog IC0gTWVobWV0OiBPbmUgb2YgdGhlIGlzc3VlcyBpczogU2hvdWxkIHRoZSBZQU5HIG1vZHVsZSBi ZSBhcyBjb21wbGV0ZSBhcyBwb3NzaWJsZT8NCiAgLSBCYWxhenM6IE1hcnRpbiBpcyBvbiBKYWJi ZXIsIHdlIHNob3VsZCBhc2sgaGltDQogIC0gTWFydGluIChvbiBKYWJiZXIpOiBZZXMsIHdlIHNo b3VsZCBtb3ZlIHRoZSB0ZXh0IHRvIHRoZSBZQU5HIG1vZHVsZS4NCiAgLSBNZWhtZXQ6IFRoZXJl IHdlcmUgYWxzbyBzb21lIGNvbW1lbnRzIGZyb20gUGhpbCB0aGF0IGhhdmVuJ3QgYmVlbiBhZGRy ZXNzZWQuDQogIC0gRGFuIGNoYW5uZWxpbmcgTWFydGluOiB5ZXMgd2Ugc2hvdWxkIG1vdmUgdGhl IHRleHQgaW50byBZYW5nDQoNCiogUkZDNDc0MWJpcyBzdGF0dXMgKEFuZHkpOg0KICAtIDAwNyBy ZXR1cm4gZnJvbSB4cGF0aCBmaWx0ZXINCiAgICAtIFRoZXJlIGlzIG5vIHRleHQgdGhhdCBzYXlz IHRoZSBub2RlcyBhcmUgcmV0dXJuZWQ7IG5vIG9yZGVyaW5nIHJlcXVpcmVkDQogICAgLSBCYWxh enM6IEkgdGhpbmsgdGhlIGlzc3VlIGlzIHdoZXRoZXIgdGhlIGtleXMgc2hvdWxkIGJlIHJldHVy bmVkIG9yIG5vdA0KICAgIC0gQW5keTogT2ssIEkgdGhpbmsgdGhhdCBzaG91bGQgYmUgdGhlIGNh c2Ugb3RoZXJ3aXNlIHRoZXJlIGlzIG5vIHdheSB0byB0ZWxsIHRoZW0gYXBhcnQuDQogICAgLSBC ZXJ0OiB5b3UgKEFuZHkpIGFuZCBNYXJ0aW4gc2hvdWxkIHNob3VsZCBwcm9wb3NlIHRleHQgYW5k IHNlbmQgdG8gbWFpbGluZyBsaXN0IGZvciBjb25zZW5zdXMgY2hlY2sNCiAgICAtIE1hcnRpbiB2 aWEgamFiYmVyOiB5ZXMgSSBiZWxpZXZlIHRoZSBrZXlzIHNob3VsZCBiZSBpbmNsdWRlZC4gTm90 ZSBpdCdzIGFsc28gZGlmZmVyZW50IGZyb20gc3VidHJlZSBmaWx0ZXJpbmcuDQogICAgLSBNYXJ0 aW46IGRpZmZlcmVudCB0aGFuIGhvdyBzdWJ0cmVlIGZpbHRlcmluZyB3b3Jrcw0KICAgIC0gaHVt IHRha2VuIGFuZCBnZW5lcmFsIGZhdm9yIHRvIGluY2x1ZGUga2V5cyB3aGVuIHJldHVybmVkDQog ICAgLSBBbmR5OiBJIGltcGxlbWVudCBzdWJ0cmVlcyB0aGUgc2FtZSB3YXkuIEl0IHJldHVybnMg a2V5cyB3aGVuIGtleXMgYXJlIG1pc3NpbmcgYW5kIGl0IGtub3dzIGl0J3MgYSBsaXN0DQogICAg LSBNYXJ0aW46IFdlIHNob3VsZCBjbGFyaWZ5IHN1YnRyZWUgZmlsdGVyaW5nIHRvIGFsbG93IGV4 dHJhIG5vZGVzIHRvIGJlIGluY2x1ZGVkLg0KICAgIC0gQmVydDogcHJvcG9zYWxzIGZvciBjb21w bGV0ZSB0ZXh0IG5lZWRlZDsgcGxlYXNlIHNlbnQgdG8gdGhlIGxpc3QuDQoNCiAgLSAwMTE6IGR1 cGxpY2F0ZSBlZGl0LWNvbmZpZyBtb2RpZmljYXRpb25zDQogICAgLSBBbmR5OiB0aGUgaXNzdWUg aXMgc2hvdWxkIHRoaXMgYmUgYW4gZXJyb3Igb3I/IEhvdyBkb2VzIHRoZSBzZXJ2ZXIgZGVhbCB3 aXRoIHRoZSBzYW1lIG9iamVjdCBhcHBlYXJpbmcgbW9yZSB0aGFuIG9uY2UNCiAgICAtIE1hcnRp biBwcm9wb3NlcyByZXN1bHQgaXMgaW1wbGVtZW50YXRpb24gc3BlY2lmaWMNCiAgICAtIExhZGE6 IFNob3VsZG4ndCBiZSBpbXBsZW1lbnRhdGlvbiBzcGVjaWZpYyBidXQgcmF0aGVyIGFuIGVycm9y IHJhaXNlZCBieSB0aGUgc2NoZW1hIHZhbGlkYXRpb24gc3Vic3lzdGVtLg0KICAgIC0gV2VzIFRo aXMgaXMgYSBjb25mbGljdCBiZXR3ZWVuIE5FVENPTkYgYW5kIE5FVE1PRC4gRnJvbSBORVRNT0Qg UE9WIHRoaXMgaXMgYW4gZXJyb3IsIGZvciBORVRDT05GIGl0J3MgT0suDQogICAgLSBCYWxhenM6 IHRoZXJlIGFyZSBvdGhlciBwcm90b2NvbHMgdGhhdCBhbGxvdyB0aGlzDQogICAgLSBBbmR5OiBi dXQgdGhlIGV4YW1wbGUgaXMgYSBsZWFmDQogICAgLSBNYXJ0aW46IEkgb2JqZWN0IHRvIGRldGVj dGluZyBhbiBlcnJvci4NCiAgICAtIExhZGlzbGF2OiBzaG91bGQgYmUgdGhlIHNjaGVtYSB0aGF0 IHZhbGlkYXRlcyBpdA0KICAgIC0gQmVydDogc2NoZW1hID0gZGF0YSBtb2RlbCBvciBwcm90b2Nv bD8gDQogICAgLSBMYWRpc2xhdjogZGF0YSBtb2RlbA0KICAgIC0gQmVydDogV2VzLCB0aGlzIG1h dGNoZXMgd2l0aCB3aGF0IHlvdSBzYWlkPw0KICAgIC0gV2VzOiB5ZXMsIEkgdGhpbmsgd2UgYXJl IGFsbCBpbiBhZ3JlZW1lbnQgLSBORVRNT0Qgc2hvdWxkIGRldGVjdCBhbiBlcnJvci4NCiAgICAt IEFuZHk6IFNlcnZlciBtYXkgY3JlYXRlIHR3byBsZWFmcyBpbiBjYW5kaWRhdGUgYW5kIG5vdCBk ZXRlY3QgaXQgdW50aWwgY29tbWl0LiBTaG91bGQgdGhlIHNlcnZlciBkZXRlY3QgdGhpcyBhcyBh biBlcnJvcj8NCiAgICAtIFdlczogaXQncyBzdGlsbCBhIG5ldG1vZCBwcm9ibGVtLiAgNDc0MSBz aG91bGQgYWxyZWFkeSBoYXZlIHRoZSB0ZXh0DQogICAgLSBNYXJ0aW46IFRoaXMgc2hvdWxkbid0 IGJlIGFsbG93ZWQuDQogICAgLSBCZXJ0OiBzbyB3ZSBzaG91bGQgZG91YmxlIGNoZWNrIHRoYXQg dGhlIGdlbmVyaWMgIm9wZXJhdGlvbnMgY2FuIHJldHVybiBhbiBlcnJvciIgYW5kIGVuc3VyZSBp dCdzIHRoZXJlLiBTcGVjaWZpYyBjaGVja3MgZm9yIGVycm9ycyBsaWtlIHRoaXMgaXMgYSBkYXRh IG1vZGVsIHNwZWNpZmljIHByb2JsZW0gdG8gZGV0ZWN0IGFuZCBmaWd1cmUgb3V0IHRoZSBleGFj dCBlcnJvciB0aGF0IHNob3VsZCBiZSByZXR1cm5lZC4NCiAgICAtIEh1bSB0YWtlbjogbWFueSBm b3IgdGhpcywgbm8gYWdhaW5zdA0KICAgIC0gQmVydDogY2FuIHdlIGdldCBBbmR5L01hcnRpbiB0 byBzYXkgdGhleSBhZ3JlZQ0KICAgIC0gQW5keTogd2Ugc2hvdWxkIHRha2UgdGhlIGRpc2N1c3Np b24gdG8gbmV0bW9kLiAgSSdtIG5vdCBzdXJlIHRoZSBlcnJvciBpcyB0aGVyZSBpbiBuZXRtb2Qg ZWl0aGVyLg0KICAgIC0gQmVydDogZnJvbSB0aGUgcHJvdG9jb2wgcG9pbnQgb2YgdmlldywgdGhp cyBpc24ndCBhIHByb3RvY29sIHByb2JsZW0gYW5kIHRoYXQncyB0aGUgY29uc2Vuc3VzIHdlJ3Jl IHRyeWluZyB0byBjaGVjay4NCg0KIC0gMDE3OiBuZXcgcmVmZXJlbmNlIGZpZ3VyZQ0KICAgLSBB bmR5OiBzbGlkZSBqdXN0IHN1Z2dlc3RzIG5ldyBkaWFncmFtDQogICAtIFdlczogU2hvdWxkIGl0 IGJlIGp1c3QgIlRyYW5zcG9ydCIgYW5kIG5vdCAiU2VjdXJlIFRyYW5zcG9ydCIgc2luY2Ugd2h5 IGxpbWl0IHlvdXJzZWxmIGFyY2hpdGVjdHVyYWxseT8gIEJ1dCBpbiB0aGUgZW5kIEkgZG9uJ3Qg Y2FyZSBlbm91Z2ggaW4gdG90YWwNCiAgIC0gQmVydDogSWYgdGhlIGVuaXZyb25tZW50IGlzIHNl Y3VyZSwgdGhlbiB0aGUgdHJhbnNwb3J0IGlzIHNlY3VyZS4NCiAgIC0gTGFkaXNsYXY6IEkgc29y dCBvZiBhZ3JlZSB3aXRoIFdlcy4gU2VjdXJpdHkgaXMgcmVsYXRpdmUsIHJhbmdpbmcgZnJvbSBu byB0byBhYnNvbHV0ZSBzZWN1cml0eSBhbmQgdGhlIGV4YW1wbGUgcHJvdG9jb2xzIGRpZmZlciBp biB0aGUgc2VjdXJpdHkgbGV2ZWwgdGhleSBwcm92aWRlLg0KICAgLSBNYXJ0aW46IHRoZSBiaWdn ZXIgY2hhbmdlIGlzIHJwYyAtPiBtZXNzYWdlcw0KICAgLSBBZ3JlZW1lbnQgdGhhdCBpdCBpcyB0 aGUgYmlnZ2VyIGNoYW5nZSwgYnV0IG5vLW9uZSBoYXMgYSBwcm9ibGVtIHdpdGggaXQuIFJvdWdo IGh1bW1pbmcgY29uc2Vuc3VzIG9uIGdvaW5nIGZvciAiU2VjdXJlIFRyYW5zcG9ydCIuDQogICAt IEp1cmdlbjogaGF2aW5nIGEgc2VjdXJlIHRyYW5zcG9ydCB3aWxsIG1hdHRlciB3aGVuIHdlIGdl dCB0byBhY2Nlc3MgY29udHJvbC4NCiAgIC0gQmVydDogcGVyc29uYWxseSBJIGxpa2UgdGhlIHNl Y3VyZSB0cmFuc3BvcnQgdGhpbmdzDQogICAtIDQ3NDEgdGV4dCBzYXlzICJ1c2luZyBhIHNlY3Vy ZSBjb25uZWN0aW9uIG9yaWVudGVkIHNlc3Npb24iDQogICAtIGh1bSB0YWtlbjsgbWF5YmUgc2xp Z2h0bHkgbGVhbmluZyB0b3dhcmQgY2hhbmdpbmcNCiAgIC0gTWVobWV0OiB3ZSBtYXkgbmVlZCB0 byBjaGFuZ2UgdGhlIHRleHQgaWYgd2UgKmRvbid0KiBjaGFuZ2UNCiAgIC0gQmFsYXpzOiB0aGVy ZSBpcyBhIGJ1bmNoIG9mIHRleHQgaW4gNDc0MSB0aGF0IGlzbid0IGluIG9mZmljaWFsIE1VU1Qv U0hPVUxEL01BWSB0ZXh0IGFuZCB0aG9zZSBzaG91bGQgYmUgY2xlYW5lZCB1cC4NCg0KIC0gMDE4 OiBMb2NrIGFuZCBDb21taXQNCiAgIC0gQW5keTogdGhpcyB3YXMgZGlzY3Vzc2VkIG9uIHRoZSBt YWlsaW5nIGxpc3Q7IHNvbWUgaW1wbGVtZW50YXRpb25zIGRpZCBoYXZlIGEgbG9jayBwcmV2ZW50 IGEgY29tbWl0IGFuZCBvdGhlcnMgZGlkIG5vdC4gIEkgbXlzZWxmIGRvbid0IGtub3cgd2hpY2gg aXMgYmV0dGVyLiBJc3N1ZSBpcyB3aGljaCBibG9ja3MgYSBjb21taXQgb3BlcmF0aW9uPyAgICAg DQogICAtIEJlcnQ6IEl0IHNvdW5kcyBsaWtlIHdlIG5lZWQgYSBjbGFyaWZpY2F0aW9uIGJ1dCB3 aGF0IHNob3VsZCBpdCBiZT8NCiAgIC0gQmFsYXpzOiBUaGUgZ2xvYmFsIGxvY2sgYWxyZWFkeSBo YXMgdHdvIHNpZGUgZWZmZWN0cyB0aGlzIHdpbGwgYWRkIGFub3RoZXIgc28gSSBvYmplY3QgdG8g aXQuDQogICAtIFdlczogRG9lcyB0aGlzIG1lYW4gdGhhdCBpZiB1c2VyIEEgaG9sZHMgdGhlIGxv Y2sgb24gY2FuZGlkYXRlLCB1c2VyIEIgaXMgbm90IGFsbG93ZWQgdG8gY29tbWl0Pw0KICAgLSBB bmR5OiBUaGF0J3MgYW5vdGhlciBpc3N1ZS4NCiAgIC0gTWFydGluOiBZZXMsIHVzZXIgQSBrZWVw cyBsb2NrLCB1c2VyIEIgY2Fubm90IGNvbW1pdC4gQnV0IEkgYW0gbm90IHN1cmUgSSBsaWtlIGl0 LiBQaGlsIGRvZXMuDQogICAtIEJlcnQ6IG5vIGNvbnNlbnN1cyBhdCB0aGUgbW9tZW50OyBzb21l b25lIHNob3VsZCB3cml0ZSBpdCB1cCBvbiB0aGUgbWFpbGluZyBsaXN0DQoNCiAtIDAwNDogZXJy b3Itc2V2ZXJpdHkNCiAgIC0gQmVydDogV2hvIHdhbnRzIHRvIHJlbW92ZSB3YXJuaW5ncz8gV2Ug bmVlZCBhIHByb3Bvc2FsLg0KICAgLSBBbmR5OiB3YXJuaW5ncyBhcmVuJ3QgdXNlZCBhbnl3aGVy ZSwgc28gaG93IGNhbiB5b3UgZXZlciByZXR1cm4gb25lPyAgV2UgZG9uJ3QgaGF2ZSBhbnl0aGlu ZyB0aGF0IHNob3VsZCByZXR1cm4gaXQuIEEgd2FybmluZyBjYW4gbm90IGJlIHJldHVybmVkIHdp dGggPG9rPiBiZWNhdXNlIG9mIHRoZSB3YXkgdGhlIFhTRCBpcyB3cml0dGVuLiBFbmRpbmcgYSB3 YXJuaW5nIHdpbGwgYWN0dWFsbHkgY29uZnVzZSBhbiBhcHBsaWNhdGlvbi4NCiAgIC0gV2VzOiBp dCdkIGJlIHVzZWZ1bCBmb3IgbmV0bW9kIG1vcmUgbGlrZWx5LiBORVRNT0QgY291bGQgbWFrZSBh IGdvb2QgdXNlIG9mIHdhcm5pbmcsIGUuZy4gaW4gdGhlIGNhc2Ugb2YgZHVwbGljYXRlIGxlYWZz Lg0KICAgLSBMYWRpc2xhdjogd291bGQgaXQgYmUgb2sgdG8gZml4IHRoZSBYU0QgYW5kIGp1c3Qg YWxsb3cgaXQgYnV0IG5vdCBkbyBhbnl0aGluZyBlbHNlPyBXb3VsZCBpdCBiZSBhbiBvcHRpb24g dG8gcGFjayBhIHdhcm5pbmcgdG9nZXRoZXIgd2l0aCA8b2svPj8NCiAgIC0gQW5keTogSSdkIHJh dGhlciBsZWF2ZSBpdCB0aGUgd2F5IGl0IHdvcmtzIG5vdy4gIEkgZG9uJ3Qgc2VlIHRoZSBiZW5l Zml0IHRvIGhhdmluZyBhbiBhcHBsaWNhdGlvbiBoYXZlIHRvIHNlYXJjaCB0aHJvdWdoIHRoZSBv ayB0YWcgZm9yIHJwYy1lcnJvciBmaWVsZHMuDQogICAtIEFuZHk6IFRoaXMgd291bGQgYnJlYWsg Y2xpZW50cy4gU3VwcG9ydGVycyBzaG91bGQgc3VnZ2VzdCBzb21ldGhpbmcuIFdlcyBjb3VsZCBw cm9wb3NlIGEgY2hhbmdlDQogICAtIFdlczogbm90IGdvbm5hIGRvIGl0DQogICAtIERhdmlkIFA6 IE1heWJlIHdlIHNob3VsZCB3YWl0IGZvciBhIHJlYWwgY2FzZSBiZWZvcmUgZml4aW5nIGl0Lg0K DQogLSAwMTQ6DQogICAtIEFuZHk6IFtub3RlIHRha2VyIGNvdWxkbid0IGhlYXIgQW5keV0NCiAg IC0gTWFydGluOiBlcnJvci1hcHAtdGFnIGNvdWxkIGJlIHVzZWQgZm9yIGNhcGFiaWxpdHktY2hh bmdlZCwgYnV0IGl0IHdhcyBzdXBwb3NlZCB0byBiZSByZXNlcnZlZCBmb3IgYXBwbGljYXRpb25z LiBNYXliZSBJIGFuZCBBbmR5IGNhbiBzZW5kIGEgcHJvcG9zYWwuDQogICAtIEJlcnQ6IE5vIGNv bnNlbnN1czsgcHJvcG9zYWxzIG5lZWRlZCB0byBtYWlsaW5nIGxpc3QuDQoNCiAtIDAxMzogY29u ZmlybWVkIGNvbW1pdA0KICAgLSBBbmR5IGlzIG5vdCBpbiBmYXZvcg0KICAgLSBGaXJzdCBpc3N1 ZTogZG8gd2UgYWdyZWUgYWJvdXQgdGhlIHByb2JsZW0uICBUaGUgc2Vzc2lvbiBtdXN0IHN0YXkg dXAuDQogICAtIEJhbGF6czogd2UgaGF2ZSBtb3JlIHRoYW4gb25lIHByb2JsZW0uICAgSWYgdGhl IHNlc3Npb24gaXMgZHJvcHBlZCBmb3Igd2hhdGV2ZXIgcmVhc29uLCBzb21lb25lIHN0aWxsIG1h eSB3YW50IHRvIGNvbW1pdCBsYXRlci4gIEkgbGlrZSB0aGUgcHJvcG9zYWwgYnV0IHdlIHNob3Vs ZCB1c2UgdXNlciBJRCByYXRoZXIgdGhhbiBzZXNzaW9uIElEIGZvciBpZGVudGlmeWluZyB0aGUg Y29tbWl0ZXIuDQogICAtIE1hcnRpbjogY3VycmVudCBpbXBsZW1lbnRhdGlvbnMgYmVoYXZlIGRp ZmZlcmVudGx5DQogICAtIEJlcnQ6IHRoZW4gdGhlIGltcGxlbWVudGF0aW9ucyBtdXN0IGRpZmZl ciBpZiBNYXJ0aW4gYW5kIEFuZHkgZGlzYWdyZWUuDQogICAtIE1hcnRpbjogdGhlcmUgaXMgbm8g dXNlciBpZA0KICAgLSBCYWxhenM6IEJ1dCB0aGUgYXNzdW1wdGlvbiBpcyB0aGF0IGFsbCBzZXNz aW9ucyBTSE9VTEQgYmUgYXV0aGVudGljYXRlZCwgc28gdXNlciBpZGVudGl0eSBzaG91bGQgYmUg a25vd24uDQogICAtIE1hcnRpbjogSXQgY2FuIGFsc28gYmUgYWNjb21wbGlzaGVkIHRocm91Z2gg Y2xpZW50IGNlcnRpZmljYXRlcy4NCiAgIC0gQmVydDogaHVtcyBpbmRpY2F0ZSBnZW5lcmFsIGFn cmVlbWVudCB0byBhbGxvdyBvdGhlciBzZXNzaW9ucyB0byBleHBsaWNpdGx5IHRvIGNvbmZpcm0N CiAgIC0gQW5keTogbm90IGluIGZhdm9yIG9mIGNoYW5naW5nIHRvIHNlc3Npb24gdG8gdXNlciBi YXNlZCBsb2Nrcy4NCiAgIC0gQmVydDsgYnJpbmcgcHJvcG9zYWwgdG8gbGlzdDsgTWFydGluIGlz IGluIGZhdm9yIHNvIGhlIHNob3VsZCB3cml0ZSB0aGUgcHJvcG9zYWwuDQoNCiAtIHNsaWRlIDEw OiBPdGhlciBpc3N1ZXM/DQogLSBCZXJ0OiBMYWNrIG9mIHRpbWUsIG90aGVyIGlzc3VlcyBzaG91 bGQgYmUgZGlzY3Vzc2VkIGluIE1MLg0KDQogKiAid2l0aC1kZWZhdWx0cyIgY2FwYWJpbGl0aWVz IGluIE5FVENPTkYNCiAtIE1hcnRpbjogVGhlIGNhcGFiaWxpdHkgc2hvdWxkIG5vdCBiZSBtYW5k YXRvcnkuDQogLSBCYWxhenM6IHRob3VnaHQgaXQgd2FzIHNpbXBsZSBidXQgdGhlcmUgaGFzIGJl ZW4gYSBsb3Qgb2YgZGlzY3Vzc2lvbi4NCiAtIG1vc3QgZGV2aWNlcyB3aWxsIGJlIGFkYXB0ZWQg ZGV2aWNlcywgbm90IGZyb20gc2NyYXRjaA0KIC0gQmFsYXpzIHRhbGtzIHRvIHNsaWRlcw0KIC0g QmVydDogSSB0aGluayB3ZSBwb3N0ZWQgdG8gdGhlIG1haWxpbmcgbGlzdCB0aGF0IHdlIHNob3Vs ZCBnYXRoZXIgdG9nZXRoZXIgcGVvcGxlIGZyb20gbmV0Y29uZi9uZXRtb2QgdG8gc29sdmUgdGhl IHByb2JsZW0uICBUaGlzIHdvcmtpbmcgZ3JvdXAgd291bGQgbmVlZCB0byBkZWZpbmUgaWYgdGhl IGNhcGFiaWxpdHkgc2hvdWxkIGJlIGEgU0hPVUxEIG9yIGEgTVVTVC4NCiAtIEJlcnQ6IGRvZXMg dGhlIHJvb20gdGhpbmsgdGhhdCB3aXRoLWRlZmF1bHRzIHNob3VsZCBiZSBhIG1hbmRhdG9yeSBj YXBhYmlsaXR5Pw0KUm91Z2ggaHVtbWluZyBjb25zZW5zdXMgb24gc2F5aW5nIHRoYXQgc2VydmVy cyBTSE9VTEQgaW1wbGVtZW50IHRoZSBjYXBhYmlsaXR5Lg0KICAgLSBIdW06IHNwbGl0IGZvciBN VVNUPw0KICAgLSBNYXJ0aW46IG5vdCBzdXJlIHdoYXQgU0hPVUxEIHdvdWxkIG1lYW4/DQogICAt IEJlcnQ6IGl0IG1lYW5zIGlmIHlvdSBkb24ndCBpbXBsZW1lbnQgaXQgeW91IGhhdmUgdG8ganVz dGlmeSB3aHkgeW91J3JlIG5vdCBpbXBsZW1lbnRpbmcgaXQuDQogICAtIEJlcnQ6IHdvdWxkIGFu eW9uZSBvYmplY3QgdG8gYSBTSE9VTEQ/ICAobm9uZSkNCiAgIC0gT2ssIEJlcnQ6IFByb3Bvc2Fs IHRoYXQgd2l0aC1kZWZhdWx0cyBjYXBhYmlsaXR5IFNIT1VMRCBiZSBpbXBsZW1lbnRlZCB3aWxs IGdvIHRvIHRoZSBNTC4gU2hvdWxkIGl0IHRoZW4gZ28gdG8gNDc0MWJpcz8NCg0KIC0gQmVydDog TmV4dCBxdWVzdGlvbjogLSBpZiB3aXRoLWRlZmF1bHRzIGlzIHN1cHBvcnRlZCwgaXMgcmVwb3J0 LWFsbCBtYW5kYXRvcnk/DQogLSBObyBvYmplY3Rpb25zDQogICAtIEJlcnQ6IG5vIG9uZSBpcyBz cGVha2luZywgc28gSSByZWFkIGNvbnNlbnN1cyB0aGF0IHdlIHdhbnQgdG8gbWFrZSByZXBvcnQt YWxsIGJlIGEgTVVTVCBpbXBsZW1lbnQgKHRvIGJlIHZlcmlmaWVkIGluIE1MKS4NCg0KIC0gc2hv dWxkIGJhc2ljIG1vZGUgYmUgY29uZmlndXJhYmxlPw0KICAgLSBCZXJ0OiBubyBkaXNjdXNzaW9u OyBtYWtlIGNvbXBsZXRlIHByb3Bvc2FsIHRvIGxpc3QNCiAtIFNoYWxsIHdlIG1ha2UgZXhwbGlj aXQgbWFuZGF0b3J5Pw0KICAgLSBCYWxhenM6IG5vIChsb3VkbHkpDQogICAtIE1hcnRpbjogZG9u J3QgbWFrZSBpdCBtYW5kYXRvcnkNCg0KIC0gU2hvdWxkIHdlIG1ha2UgMyBmZWF0dXJlcy9jYXBh YmlsaXRpZXMgaW5zdGVhZCBvZiBvbmU/DQogICAtIEJhbGF6czogbm8sIGl0J3Mgc2ltcGxlLg0K ICAgLSBubyBjb21tZW50czsgbm90aGluZyB3aWxsIGhhcHBlbg0KICAgLSBCYWxhenM6IEkgcHJl ZmVyIG9uZSBjYXBhYmlsaXR5Lg0KICAgLSBNYXJ0aW46IEkgYWdyZWUgd2l0aCBCYWxhenMuDQog ICAtIEFuZHk6IE9uZSBjYXBhYmlsaXR5LCBub3QgdGhyZWUuDQogICAtIEJlcnQ6IGNvbnNlbnN1 czogd2Ugd2FudCB3aGF0J3MgaW4gdGhlIGRvY3VtZW50IHJpZ2h0IG5vdy4NCiAgICAgRG91Ymxl IGNoZWNrIGNvbnNlbnN1cyBvbiBsaXN0Lg0KDQogLSBJdCB3b3VsZCBiZSBtb3JlIGNvcnJlY3Qg dG8gc3BlYWsgb2Ygb3BlcmF0aW9ucyBpbnN0ZWFkIG9mIHJwY3MNCiAgIC0gQmFsYXpzOyBJIHNl ZSB0aGF0LCBidXQgb3RoZXIgZG9jdW1lbnRzIGFyZSB3cml0dGVuIHRoZSBvdGhlciB3YXlzLg0K ICAgLSBCZXJ0OiBpZiB3ZSBkbyBpdCB0aGVuIHdlIHNob3VsZCBkbyBpdCBpbiA0NzQxYmlzIHRv bw0KICAgLSBCZXJ0OiBwZXJzb25hbCBvcGluaW9uIGlzIHRvIGxlYXZlIGFzIGlzDQogICAtIEh1 bTogbGVhdmUgYXMgaXMgKG5vbmUgb3Bwb3NlZCksIFJQQ3MgYXJlIHVzZWQgaW4gb3RoZXIgZG9j dW1lbnRzLg0KDQogLSBTaG91bGQgd2Ugd2FpdCBmb3IgWUFORyBhbmQgNDc0MWJpcyB0byBtYWtl IFlBTkcgbWFuZGF0b3J5Pw0KICAgLSBCYWxhenM6IGl0IHdvdWxkIGJlIG5pY2UsIGJ1dCBpdCBt aWdodCB0YWtlIGEgbG9uZyB0aW1lDQogICAtIE1laG1ldDogV2UgaGFkIGluY29uc2lzdGVuY2ll cyBpbiBtb25pdG9yaW5nIGRyYWZ0LiAgSWYgd2UgZG9uJ3QgaGF2ZSBzaW1pbGFyIGlzc3VlcyBo ZXJlIGFzIGEgY29udHJpYnV0b3IgSSBhbSBpbiBmYXZvciBvZiBwdXNoaW5nIHRoZSBkcmFmdCBh cyBpdCBpcy4NCiAgIC0gQmFsYXpzOiBubw0KICAgLSBCYWxhenM6IG15IG90aGVyIHByb2JsZW0g aXMgdGhhdCBpZiB3ZSB3YW50IHRvIG1ha2UgYSBmb3JtYWwgZGVzY3JpcHRpb24gdGhlbiB3ZSBo YXZlIHRvIHdhaXQgZm9yIGJvdGggNDc0MWJpcyBhbmQgeWFuZyBhbmQNCiAgICAgNDc0MWJpcyBt YXkgdGFrZSBhIGxvbmcgdGltZQ0KICAgLSBBbmR5OiBJIGRvIG5vdCBvYmplY3QgdG8gcHVibGlz aGluZyBhc2FwIHdpdGggeHNkIGFuZCBub3QgeWFuZw0KDQogKiA0NzQyYmlzIChCZXJ0KToNCiAt IGlzc3VlczoNCiAgIC0gZXJyYXRhIHZpYSBSRkMgZWRpdG9yIGFwcHJvdmVkIG5vdw0KICAgLSB4 bWwgc3RhcnQgZGlyZWN0aXZlIHdpdGggc3NoDQogICAtIFNTSC10cmFuc3BvcnQgZm9yIG5vdGlm aWNhdGlvbnM/DQogLSBCZXJ0OiBBcmUgdGhlcmUgYW55IG90aGVyIGlzc3Vlcz8NCiAgIC0gQmFs YXpzOiBUaGVyZSBpcyBhbHNvIHRoZSBwcm9ibGVtIG9mIHRlcm1pbmF0aW5nIHNlcXVlbmNlICJd XT5dXT4iLg0KICAgLSBMYWRhOiBJdCB3YXMgYWNrbm93bGVkZ2VkIGFzIGEgcHJvYmxlbSBidXQg dGhlIGNvbnNlbnN1cyB3YXMgdG8gbGVhdmUgaXQgYXMgaXQgaXMgYmVjYXVzZSBhbnkgY2hhbmdl IHdvdWxkIGJyZWFrIGNsaWVudHMgYW5kIHRoZSBwb3RlbnRpYWwgcmlzayBpcyBub3QgdGhhdCBo aWdoLg0KICAgLSBCZXJ0OiBTbyBpdCdzIG5vdCBhbiBvcGVuIGlzc3VlIGFueW1vcmUuDQoNCiAt IEJlcnQ6DQogICAtIFdlIG5lZWQgZWRpdG9ycy4gIE1hcmdhcmV0IFdhc3Nlcm1hbiB3b3VsZCBi ZSB3aWxsaW5nDQogICAtIEFuZHk6IFJGQyA0NzQyIHNob3VsZCBiZSB1cGRhdGVkIGlmIHRoZSBh dXRob3JzIGFyZSB3aWxsaW5nIHRvIGRvIGl0Lg0KICAgLSBodW06IHNob3VsZCB3ZSB0cnkgdG8g Z2V0IGl0IG91dCBhdCB0aGUgc2FtZSB0aW1lPw0KICAgICAtICJzaHkgaHVtIg0KDQo= ------_=_NextPart_001_01CA6B97.118AB635-- From bertietf@bwijnen.net Mon Nov 23 00:10:16 2009 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CAEE03A68A6; Mon, 23 Nov 2009 00:10:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.188 X-Spam-Level: X-Spam-Status: No, score=-7.188 tagged_above=-999 required=5 tests=[AWL=-4.078, BAYES_05=-1.11, GB_I_LETTER=-2] 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 tR0mMo2ctFjl; Mon, 23 Nov 2009 00:10:15 -0800 (PST) Received: from postlady.ripe.net (postlady.ripe.net [193.0.19.65]) by core3.amsl.com (Postfix) with ESMTP id 4264A3A67F3; Mon, 23 Nov 2009 00:10:13 -0800 (PST) Received: from herring.ripe.net ([193.0.1.203]) by postlady.ripe.net with esmtp (Exim 4.63) (envelope-from ) id 1NCTzs-0008R0-PA; Mon, 23 Nov 2009 09:10:08 +0100 Received: from ayeaye.ripe.net (ayeaye.ripe.net [193.0.1.103]) by herring.ripe.net (Postfix) with ESMTP id BC3B22F583; Mon, 23 Nov 2009 09:10:08 +0100 (CET) Received: from dog.ripe.net ([193.0.1.217] helo=guest-106.ripe.net) by ayeaye.ripe.net with esmtp (Exim 4.63) (envelope-from ) id 1NCTzs-0001NL-Lz; Mon, 23 Nov 2009 09:10:08 +0100 Message-ID: <4B0A4362.7070405@bwijnen.net> Date: Mon, 23 Nov 2009 08:10:10 +0000 From: "Bert (IETF) Wijnen" User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: Netconf , netmod@ietf.org Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-RIPE-Signature: 86ab03e524994f79ca2c75a176445dd473427ef13626cca42930a1036735bed7 Subject: [Netconf] Tentative Netconf/Netmod interoperability event X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Nov 2009 08:10:16 -0000 Netconf and Netmod WG participants, and specifically any implementers, Some of your WG chairs were informed bout a tentative interoperability event right before the next IETF meeting in Anaheim. We are not endorsing the company that organizes this, but thought it would be good to make you all aware. For more details, pls go to: http://www.iwl.com/winter-2009-newsletter.html interoperability testing is in general a good thing of course. Bert From MARKSCOT@nortel.com Mon Nov 23 13:29:57 2009 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 35B563A67D9 for ; Mon, 23 Nov 2009 13:29:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.597 X-Spam-Level: X-Spam-Status: No, score=-6.597 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, HTML_OBFUSCATE_05_10=0.001, RCVD_IN_DNSWL_MED=-4] 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 CDoHdpbhrxRT for ; Mon, 23 Nov 2009 13:29:52 -0800 (PST) Received: from zrtps0kp.nortel.com (zrtps0kp.nortel.com [47.140.192.56]) by core3.amsl.com (Postfix) with ESMTP id 7F1943A67AA for ; Mon, 23 Nov 2009 13:29:52 -0800 (PST) Received: from zcarhxm2.corp.nortel.com (zcarhxm2.corp.nortel.com [47.129.230.99]) by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id nANLThU29746 for ; Mon, 23 Nov 2009 21:29:43 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CA6C84.125D23FE" Date: Mon, 23 Nov 2009 16:29:42 -0500 Message-ID: <713043CE8B8E1348AF3C546DBE02C1B41B48EB78@zcarhxm2.corp.nortel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: darft-ietf-netconf-monitoring: some proposed changes for v10 for comment Thread-Index: AcpshBGtr8od+7OeRc22GDJO5SkQ7A== From: "Mark Scott" To: Subject: [Netconf] darft-ietf-netconf-monitoring: some proposed changes for v10 for comment X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Nov 2009 21:29:57 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CA6C84.125D23FE Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello, =20 There are some specific changes planned for the next revision of the monitoring draft which we'd like to share with the ML in advance of the next draft publication. Other changes based on WGLC comments will be shared in the updated draft. =20 Proposed changes: =20 1. Title change from 'NETCONF Monitoring Schema' to 'YANG Module for NETCONF Monitoring' =20 2. Namespace change from 'urn:ietf:params:xml:ns:netconf:state' to 'urn:ietf:params:xml:ns:yang:ietf-netconf-monitoring:DRAFT-10' =20 3. YANG module change from 'ietf-netconf-state' to 'ietf-netconf-monitoring' =20 4. Top-level container change from 'netconf-state' to 'ietf-netconf-monitoring' =20 The rationale for these changes is consistency and alignment with the yang module usage guidelines (see http://tools.ietf.org/html/draft-ietf-netmod-yang-usage-02). =20 Please send any comments to the ML prior to Nov 26th if you object to these changes.=20 =20 cheers, Mark =20 =20 "The author works for Telefonaktiebolaget L M Ericsson ("Ericsson"), who is solely responsible for this email and its contents. All inquiries regarding this email should be addressed to Ericsson. Nortel has provided the use of the nortel.com domain to Ericsson in connection with this email solely for the purpose of connectivity and Nortel Networks has no liability for the email or its contents. The web site for Ericsson is www.ericsson.com ." =20 ------_=_NextPart_001_01CA6C84.125D23FE Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hello,

 

There are some specific changes planned for the = next revision of the monitoring draft which we’d like to share with the = ML in advance of the next draft publication.  Other changes based on WGLC = comments will be shared in the updated draft.

 

Proposed changes:

 

1.       Title change from ‘NETCONF Monitoring = Schema’ to ‘YANG Module for NETCONF = Monitoring’

 

2.       Namespace change from = ‘urn:ietf:params:xml:ns:netconf:state’ to = ‘urn:ietf:params:xml:ns:yang:ietf-netconf-monitoring:DRAFT-10’

 

3.       YANG module change from = ‘ietf-netconf-state’ to ‘ietf-netconf-monitoring’

 

4.       Top-level container change from = ‘netconf-state’ to ‘ietf-netconf-monitoring’

 

The rationale for these changes is consistency and = alignment with the yang module usage guidelines (see http:= //tools.ietf.org/html/draft-ietf-netmod-yang-usage-02).

 

Please send any comments to the ML prior to Nov = 26th if you object to these changes.

 

cheers,

Mark

 

 

“The author works for Telefonaktiebolaget L M Ericsson (“Ericsson”), who is solely responsible for this email and = its contents. All inquiries regarding this email should be addressed to = Ericsson. Nortel has provided the use of the nortel.com domain to Ericsson in = connection with this email solely for the purpose of connectivity and Nortel = Networks has no liability for the email or its contents. The web site for Ericsson is = www.ericsson.com.”

 

------_=_NextPart_001_01CA6C84.125D23FE-- From j.schoenwaelder@jacobs-university.de Mon Nov 23 13:52:17 2009 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BCE0128C1BF for ; Mon, 23 Nov 2009 13:52:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.983 X-Spam-Level: X-Spam-Status: No, score=-1.983 tagged_above=-999 required=5 tests=[AWL=0.266, BAYES_00=-2.599, HELO_EQ_DE=0.35] 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 3UGnNCfkXFNC for ; Mon, 23 Nov 2009 13:52:17 -0800 (PST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 9BE163A6A18 for ; Mon, 23 Nov 2009 13:52:09 -0800 (PST) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 66A7CC0014; Mon, 23 Nov 2009 22:52:05 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius2.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 20X0wS2SJ7dy; Mon, 23 Nov 2009 22:52:04 +0100 (CET) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 22F48C0010; Mon, 23 Nov 2009 22:52:04 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 2746BE330B9; Mon, 23 Nov 2009 22:52:03 +0100 (CET) Date: Mon, 23 Nov 2009 22:52:03 +0100 From: Juergen Schoenwaelder To: Mark Scott Message-ID: <20091123215203.GA9240@elstar.local> Mail-Followup-To: Mark Scott , "netconf@ietf.org" References: <713043CE8B8E1348AF3C546DBE02C1B41B48EB78@zcarhxm2.corp.nortel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <713043CE8B8E1348AF3C546DBE02C1B41B48EB78@zcarhxm2.corp.nortel.com> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: "netconf@ietf.org" Subject: [Netconf] YANG module naming conventions (was Re: darft-ietf-netconf-monitoring: some proposed changes for v10 for comment) X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Nov 2009 21:52:17 -0000 On Mon, Nov 23, 2009 at 10:29:42PM +0100, Mark Scott wrote: > 4. Top-level container change from ?netconf-state? to > ?ietf-netconf-monitoring? > The rationale for these changes is consistency and alignment with > the yang module usage guidelines (see > http://tools.ietf.org/html/draft-ietf-netmod-yang-usage-02). I fail to find the guideline in netmod-yang-usage-02 that leads to a toplevel name like ietf-netconf-monitoring. I am not saying its wrong just that I do not understand the pointer to netmod-yang-usage-02. I guess I am missing a plan for a general strategy. If we have an IETF protocol 'foo', do we expect YANG modules such as: YANG module YANG toplevel YANG contents ietf-foo-monitoring ietf-foo-monitoring config false objects ietf-foo-config ietf-foo-config config true objects ietf-foo - typedefs, groupings, rpcs Do we also allow / expect the following: ietf-foo-types - typedefs, groupings ietf-foo-ops - operations Is the namespace always going to be urn:ietf:params:xml:ns:yang:$MODULE-NAME[:DRAFT-$VERSION]? Should ietf-foo-monitoring be in general ietf-foo-state or do we have yet separate modules to report operational state? Perhaps the answer to all this is we do not know - but I thought I at least bring up the question so we don't do things by accident. /js PS: I am CCing NETMOD since this is mostly an YANG issue. Further discussion should likely stay in NETMOD, assuming the NETCONF monitoring people are on NETMOD as well. -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From mbj@tail-f.com Mon Nov 23 15:05:50 2009 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 880B43A6AAC; Mon, 23 Nov 2009 15:05:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.046 X-Spam-Level: X-Spam-Status: No, score=-2.046 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] 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 j1Rza9dOqxJc; Mon, 23 Nov 2009 15:05:49 -0800 (PST) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id 819443A681D; Mon, 23 Nov 2009 15:05:49 -0800 (PST) Received: from localhost (c213-100-167-236.swipnet.se [213.100.167.236]) by mail.tail-f.com (Postfix) with ESMTPSA id 61718616001; Tue, 24 Nov 2009 00:00:01 +0100 (CET) Date: Tue, 24 Nov 2009 00:00:00 +0100 (CET) Message-Id: <20091124.000000.152719236.mbj@tail-f.com> To: j.schoenwaelder@jacobs-university.de From: Martin Bjorklund In-Reply-To: <20091123215203.GA9240@elstar.local> References: <713043CE8B8E1348AF3C546DBE02C1B41B48EB78@zcarhxm2.corp.nortel.com> <20091123215203.GA9240@elstar.local> X-Mailer: Mew version 6.2.51 on Emacs 22.2 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org, netconf@ietf.org Subject: Re: [Netconf] YANG module naming conventions X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Nov 2009 23:05:50 -0000 Hi, Juergen Schoenwaelder wrote: > On Mon, Nov 23, 2009 at 10:29:42PM +0100, Mark Scott wrote: > > > 4. Top-level container change from ?netconf-state? to > > ?ietf-netconf-monitoring? > > > The rationale for these changes is consistency and alignment with > > the yang module usage guidelines (see > > http://tools.ietf.org/html/draft-ietf-netmod-yang-usage-02). > > I fail to find the guideline in netmod-yang-usage-02 that leads to a > toplevel name like ietf-netconf-monitoring. I am not saying its wrong > just that I do not understand the pointer to netmod-yang-usage-02. I also noted this, and we had this discussion some time ago. At this point, I don't think we should change it from netconf-state. > I guess I am missing a plan for a general strategy. If we have an IETF > protocol 'foo', do we expect YANG modules such as: > > YANG module YANG toplevel YANG contents > > ietf-foo-monitoring ietf-foo-monitoring config false objects > ietf-foo-config ietf-foo-config config true objects > ietf-foo - typedefs, groupings, rpcs > > Do we also allow / expect the following: > > ietf-foo-types - typedefs, groupings > ietf-foo-ops - operations Hopefully not... Looking at the netconf case, I think everything could be under 'netconf'. But not in the urn:...:ietf-netconf-monitoring namespace. Maybe it would be better to use a more generic namespace for netconf state and monitoring, and put monitoring in its own submodule(s) and config in other submodule(s). > Is the namespace always going to be > urn:ietf:params:xml:ns:yang:$MODULE-NAME[:DRAFT-$VERSION]? It is slightly redundant, since the $MODULE-NAME is on the form 'ietf-NAME'. I think urn:ietf:params:xml:ns:yang:netconf-monitoring would be fine. > Should ietf-foo-monitoring be in general ietf-foo-state or do we have > yet separate modules to report operational state? Perhaps the answer > to all this is we do not know - but I thought I at least bring up the > question so we don't do things by accident. > > /js > > PS: I am CCing NETMOD since this is mostly an YANG issue. Further > discussion should likely stay in NETMOD, assuming the NETCONF > monitoring people are on NETMOD as well. I think you forgot that, so I'm doing it now. /martin From andy@netconfcentral.com Mon Nov 23 15:16:27 2009 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BFC913A6778 for ; Mon, 23 Nov 2009 15:16:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.938 X-Spam-Level: X-Spam-Status: No, score=-1.938 tagged_above=-999 required=5 tests=[AWL=-0.540, BAYES_00=-2.599, J_CHICKENPOX_64=0.6, J_CHICKENPOX_65=0.6, UNPARSEABLE_RELAY=0.001] 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 TSQzaqdD3fJh for ; Mon, 23 Nov 2009 15:16:27 -0800 (PST) Received: from smtp104.sbc.mail.mud.yahoo.com (smtp104.sbc.mail.mud.yahoo.com [68.142.198.203]) by core3.amsl.com (Postfix) with SMTP id DF2193A67BD for ; Mon, 23 Nov 2009 15:16:26 -0800 (PST) Received: (qmail 54119 invoked from network); 23 Nov 2009 23:16:20 -0000 Received: from adsl-67-125-158-117.dsl.irvnca.pacbell.net (andy@67.125.158.117 with plain) by smtp104.sbc.mail.mud.yahoo.com with SMTP; 23 Nov 2009 15:16:20 -0800 PST X-Yahoo-SMTP: Z6xhxCCswBAlhcxjVNwaQtp4EKpLdTUUf5Nx_pGy81o- X-YMail-OSG: rekJdWIVM1nknBmTtzqRzwsihgWzRtRtF8Jgk3fJmbOHGI_pg9cQlxUecAMsCGq1FGOAaGwnjIMv66NaSKsc27HzdinzaejbQ48j3z2BmhGYLUQlPdXW9OaVyImDi9ROy.gv_IGtasBPtZexGRqQatAApSCim3pRhht7Nn_SHrblreiPiVho8NzUzNfUGZBfwDvj7_RaP3WGwAKBOoeLDuTmODEo3nrvFBBJuOocNEB5V83mAq3UzT9PsX8p.vOeDZjvVSJoqCmm2eCrXp0pns4a9eq7JpgOIuc0Fw4pdw1MFgdLFD.8Taj3DD44fC.qREgyhnTPqQj0PjeoerLRzd9fkbJxnqJSPgkvEDGJmv9AKkqp X-Yahoo-Newman-Property: ymail-3 Message-ID: <4B0B1739.7090502@netconfcentral.com> Date: Mon, 23 Nov 2009 15:14:01 -0800 From: Andy Bierman User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: Martin Bjorklund References: <713043CE8B8E1348AF3C546DBE02C1B41B48EB78@zcarhxm2.corp.nortel.com> <20091123215203.GA9240@elstar.local> <20091124.000000.152719236.mbj@tail-f.com> In-Reply-To: <20091124.000000.152719236.mbj@tail-f.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: netconf@ietf.org, netmod@ietf.org Subject: Re: [Netconf] YANG module naming conventions X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Nov 2009 23:16:27 -0000 Martin Bjorklund wrote: > Hi, > > Juergen Schoenwaelder wrote: >> On Mon, Nov 23, 2009 at 10:29:42PM +0100, Mark Scott wrote: >> >>> 4. Top-level container change from ?netconf-state? to >>> ?ietf-netconf-monitoring? >>> The rationale for these changes is consistency and alignment with >>> the yang module usage guidelines (see >>> http://tools.ietf.org/html/draft-ietf-netmod-yang-usage-02). >> I fail to find the guideline in netmod-yang-usage-02 that leads to a >> toplevel name like ietf-netconf-monitoring. I am not saying its wrong >> just that I do not understand the pointer to netmod-yang-usage-02. > > I also noted this, and we had this discussion some time ago. At this > point, I don't think we should change it from netconf-state. > I agree. I am not sure if there is still a guideline that says the top-level container should be the same as the module name. This is not really needed. The module name is not a QName so it needs special naming considerations. The top-level element is a QName and there are no naming collisions to worry about (because the namespace URI was picked to be globally unique.) >> I guess I am missing a plan for a general strategy. If we have an IETF >> protocol 'foo', do we expect YANG modules such as: >> >> YANG module YANG toplevel YANG contents >> >> ietf-foo-monitoring ietf-foo-monitoring config false objects >> ietf-foo-config ietf-foo-config config true objects >> ietf-foo - typedefs, groupings, rpcs >> >> Do we also allow / expect the following: >> >> ietf-foo-types - typedefs, groupings >> ietf-foo-ops - operations > > Hopefully not... > > Looking at the netconf case, I think everything could be under > 'netconf'. But not in the urn:...:ietf-netconf-monitoring namespace. > We went though this issue awhile back. one container was config=true and the other was config=false. So one was renamed to netconf-state instead of augmenting the 4741 netconf node. > Maybe it would be better to use a more generic namespace for netconf > state and monitoring, and put monitoring in its own submodule(s) and > config in other submodule(s). > >> Is the namespace always going to be >> urn:ietf:params:xml:ns:yang:$MODULE-NAME[:DRAFT-$VERSION]? > > It is slightly redundant, since the $MODULE-NAME is on the form > 'ietf-NAME'. I think > > urn:ietf:params:xml:ns:yang:netconf-monitoring > > would be fine. > > >> Should ietf-foo-monitoring be in general ietf-foo-state or do we have >> yet separate modules to report operational state? Perhaps the answer >> to all this is we do not know - but I thought I at least bring up the >> question so we don't do things by accident. >> >> /js >> >> PS: I am CCing NETMOD since this is mostly an YANG issue. Further >> discussion should likely stay in NETMOD, assuming the NETCONF >> monitoring people are on NETMOD as well. > > I think you forgot that, so I'm doing it now. > > > /martin Andy From mrw@lilacglade.org Tue Nov 24 05:16:14 2009 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E01573A68A2 for ; Tue, 24 Nov 2009 05:16:14 -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 mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FD5EpMIFLHFV for ; Tue, 24 Nov 2009 05:16:13 -0800 (PST) Received: from QMTA13.emeryville.ca.mail.comcast.net (qmta13.emeryville.ca.mail.comcast.net [76.96.27.243]) by core3.amsl.com (Postfix) with ESMTP id 7E0AF3A6831 for ; Tue, 24 Nov 2009 05:16:12 -0800 (PST) Received: from OMTA24.emeryville.ca.mail.comcast.net ([76.96.30.92]) by QMTA13.emeryville.ca.mail.comcast.net with comcast id 913n1d00B1zF43QAD1G9wo; Tue, 24 Nov 2009 13:16:09 +0000 Received: from [10.36.0.42] ([98.110.239.206]) by OMTA24.emeryville.ca.mail.comcast.net with comcast id 91Fy1d00D4Tt8He8k1G2mM; Tue, 24 Nov 2009 13:16:09 +0000 Message-Id: <0BA2BFF6-C05A-46FA-B8E9-AF2AEDD95665@lilacglade.org> From: Margaret Wasserman To: Andy Bierman Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Tue, 24 Nov 2009 08:15:54 -0500 X-Mailer: Apple Mail (2.936) Cc: netconf@ietf.org Subject: Re: [Netconf] xml start directive with ssh X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Nov 2009 13:16:15 -0000 Hi Andy, Andy Bierman wrote: > WashamFan wrote: >> From this sentence: >> >> Implementations MUST skip >> over these messages by searching for an 'xml' start directive, which >> MUST be followed by a element in the 'NETCONF' namespace. >> >> message with an XML declaration is a MUST. > This text is a perfect example of the "CLI mentality" in place when NETCONF > was written. It was assumed that implementations would do a normal CLI login, > and then magically (or manually) switch to "NETCONF mode", after a bunch of > screen-scraping. (Wrong!) I'm working on an update for RFC4742bis starting from the -06 version of the draft that we submitted to the IESG, and I thought you might be interested to know that the text quoted above was not in the Internet Draft that the WG submitted to the IESG; it was added as an IESG note in the late stages of document approval. I can't tell from the tracker why it was added, but there is no indication that it reflected the WG's mentality at all. The actual RFC editor note is included below. Our original text only concerned the case of SSHv1, when a subsystem would not be available -- this was something we discussed in the WG back then, although it isn't really an issue today. When the text was modified (via the RFC editor note) during IESG review, that distinction was elminated and the additional requirement for an XML start directive was added. Given that Bert was the AD at the time, and he was always careful about these things, I am sure that the netconf WG chairs (Andy and Simon Leinin) and the document authors (Ted Goddard and I) saw this RFC editor note and explicitly approved it. So, Andy, it looks like you, Bert and I can blame ourselves for this mistake, but it would be unfair to blame the WG. Fortunately, we now have an opportunity to correct it. Margaret - In section 3, page 3 (last line) and 4: OLD: SSHv1. Running NETCONF as an SSH subsystem avoids the need for the script to recognize shell prompts or skip over extraneous information, such as a system message that is sent at shell start-up. However, if a subsystem cannot be used, it should be possible for a client to skip over any system messages that are sent at shell start-up by searching for a NETCONF element. Note that this may not avoid problems if system messages are recieved later in the session. NEW: SSHv1. Running NETCONF as an SSH subsystem avoids the need for the script to recognize shell prompts or skip over extraneous information, such as a system message that is sent at shell start-up. However, even when a subsystem is used, some extraneous messages may be printed by the user's start-up scripts. Implementations MUST skip over these messages by searching for an 'xml' start directive, which MUST be followed by a element in the 'NETCONF' namespace. From bertietf@bwijnen.net Tue Nov 24 13:30:15 2009 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3C3683A6907 for ; Tue, 24 Nov 2009 13:30:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.456 X-Spam-Level: * X-Spam-Status: No, score=1.456 tagged_above=-999 required=5 tests=[AWL=-0.702, BAYES_50=0.001, HELO_MISMATCH_NET=0.611, HOST_EQ_NL=1.545, HTML_MESSAGE=0.001] 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 bonfs3-8eCag for ; Tue, 24 Nov 2009 13:30:14 -0800 (PST) Received: from relay.versatel.net (relay56.tele2.vuurwerk.nl [62.250.3.56]) by core3.amsl.com (Postfix) with ESMTP id 1D2A93A6819 for ; Tue, 24 Nov 2009 13:30:13 -0800 (PST) Received: from [87.215.199.34] (helo=BertLaptop) by relay.versatel.net with smtp (Exim 4.69) (envelope-from ) id 1ND2xc-0000I9-Od for netconf@ietf.org; Tue, 24 Nov 2009 22:30:08 +0100 Message-ID: <8051C60F8BA0481692D907F1ED03D1C4@BertLaptop> From: "Bert Wijnen \(IETF\)" To: "Netconf" Date: Tue, 24 Nov 2009 22:29:45 +0100 Organization: Consultant MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_1C5B_01CA6D55.A0026640" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Windows Mail 6.0.6002.18005 X-MimeOLE: Produced By Microsoft MimeOLE V6.0.6002.18005 Subject: [Netconf] Poll for WG consensus on doing a rfc4742bis X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Nov 2009 21:30:15 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_1C5B_01CA6D55.A0026640 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable WG participants, The two authors/editors of RFC4742 have agreed to pick up the pen if we indeed want to produce a RFC4742bis. Maragert will do the bulk of the editing though. At the IETF76 meeting we had consensus to do an RFC4742bis.=20 Our current WG charter allows for this. All we need to do is add a = milestone. The proposed milestones are: - dec 2009 publish initial wg draft for rfc4742bis - 1Q 2010 WG Last Call rfc4742bis - 2Q 2010 send rfc4742bis to IESG for publication as stdsa track RFC. But we need to confirm this on the mailing list. So please speak up ASAP, but no later than Dec 1st, if you feel we = should not undertake that work. We (WG-chairs) will take silence as agreement = this time. Bert & Mehmet ------=_NextPart_000_1C5B_01CA6D55.A0026640 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
WG participants,
 
The two  authors/editors of RFC4742 have agreed = to pick=20 up the pen if we
indeed want to produce a RFC4742bis. Maragert will = do the=20 bulk
of the editing though.
 
At the IETF76 meeting we had consensus to do an = RFC4742bis.=20
Our current WG charter allows for this. All we need = to do is=20 add a milestone.
The proposed milestones are:
 
- dec 2009  publish initial wg draft for=20 rfc4742bis
- 1Q 2010   WG Last Call = rfc4742bis
- 2Q 2010   send rfc4742bis to IESG for = publication=20 as stdsa track RFC.
 
But we need to confirm this on = the mailing=20 list.
 
So please speak up ASAP, but no later than Dec 1st, = if you=20 feel we should
not undertake that work. We (WG-chairs) will take = silence as=20 agreement this time.
 
Bert & Mehmet
------=_NextPart_000_1C5B_01CA6D55.A0026640-- From lhotka@cesnet.cz Wed Nov 25 09:44:15 2009 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E779A3A6AF2 for ; Wed, 25 Nov 2009 09:44:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.117 X-Spam-Level: X-Spam-Status: No, score=-1.117 tagged_above=-999 required=5 tests=[AWL=0.133, BAYES_00=-2.599, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904] 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 OjGgF8ZDjmcX for ; Wed, 25 Nov 2009 09:44:15 -0800 (PST) Received: from office2.cesnet.cz (office2.cesnet.cz [195.113.144.244]) by core3.amsl.com (Postfix) with ESMTP id 9678E3A694C for ; Wed, 25 Nov 2009 09:44:14 -0800 (PST) Received: from [172.29.2.201] (asus-gx.lhotka.cesnet.cz [195.113.161.161]) by office2.cesnet.cz (Postfix) with ESMTP id C7E93D800CC for ; Wed, 25 Nov 2009 18:44:08 +0100 (CET) From: Ladislav Lhotka To: netconf@ietf.org In-Reply-To: <0BA2BFF6-C05A-46FA-B8E9-AF2AEDD95665@lilacglade.org> References: <0BA2BFF6-C05A-46FA-B8E9-AF2AEDD95665@lilacglade.org> Content-Type: text/plain; charset="UTF-8" Organization: CESNET Date: Wed, 25 Nov 2009 18:44:07 +0100 Message-ID: <1259171047.19603.18.camel@missotis> Mime-Version: 1.0 X-Mailer: Evolution 2.28.1 Content-Transfer-Encoding: 8bit Subject: Re: [Netconf] xml start directive with ssh X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Nov 2009 17:44:16 -0000 Margaret Wasserman píše v Út 24. 11. 2009 v 08:15 -0500: > Hi Andy, > > Andy Bierman wrote: > > WashamFan wrote: > >> From this sentence: > >> > >> Implementations MUST skip > >> over these messages by searching for an 'xml' start directive, which > >> MUST be followed by a element in the 'NETCONF' namespace. > >> > >> message with an XML declaration is a MUST. > > > This text is a perfect example of the "CLI mentality" in place when > NETCONF > > was written. It was assumed that implementations would do a normal > CLI login, > > and then magically (or manually) switch to "NETCONF mode", after a > bunch of > > screen-scraping. (Wrong!) > > I'm working on an update for RFC4742bis starting from the -06 version > of the draft that we submitted to the IESG, and I thought you might be > interested to know that the text quoted above was not in the Internet > Draft that the WG submitted to the IESG; it was added as an IESG note > in the late stages of document approval. I can't tell from the > tracker why > it was added, but there is no indication that it reflected the WG's > mentality at all. As a relative newcomer, I am surprised that such things can so easily happen, given the otherwise meticulous IETF workflow. Another such mishap was the terminating sequence "]]>]]>" - from the mailing list archive, it seems there was a strong agreement in the WG, but on something completely different, namely on using processing instruction for this purpose. But this probably cannot be undone any more. Lada > > The actual RFC editor note is included below. Our original text only > concerned the case of SSHv1, when a subsystem would not be > available -- this was something we discussed in the WG back then, > although it isn't really an issue today. When the text was modified > (via the RFC editor note) during IESG review, that distinction was > elminated and the additional requirement for an XML start directive > was added. > > Given that Bert was the AD at the time, and he was always careful > about these things, I am sure that the netconf WG chairs (Andy and > Simon Leinin) and the document authors (Ted Goddard and I) saw > this RFC editor note and explicitly approved it. So, Andy, it looks > like you, Bert and I can blame ourselves for this mistake, but it would > be unfair to blame the WG. Fortunately, we now have an opportunity to > correct it. > > Margaret > > > - In section 3, page 3 (last line) and 4: > > OLD: > > SSHv1. Running NETCONF as an SSH subsystem avoids the need for > the script to recognize shell prompts or skip over extraneous > information, > such as a system message that is sent at shell start-up. However, if a > subsystem cannot be used, it should be possible for a client to skip > over > any system messages that are sent at shell start-up by searching for a > NETCONF element. Note that this may not avoid problems if > system messages are recieved later in the session. > > NEW: > > SSHv1. Running NETCONF as an SSH subsystem avoids the need for the > script to recognize shell prompts or skip over extraneous information, > such > as a system message that is sent at shell start-up. However, even when a > subsystem is used, some extraneous messages may be printed by the user's > start-up scripts. Implementations MUST skip over these messages by > searching for an 'xml' start directive, which MUST be followed by a > > element in the 'NETCONF' namespace. > > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf -- Ladislav Lhotka, CESNET PGP Key ID: E74E8C0C From mrw@lilacglade.org Wed Nov 25 13:12:38 2009 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 28AA83A695D for ; Wed, 25 Nov 2009 13:12:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.265 X-Spam-Level: X-Spam-Status: No, score=-2.265 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] 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 voL16qZH6TQU for ; Wed, 25 Nov 2009 13:12:38 -0800 (PST) Received: from QMTA04.emeryville.ca.mail.comcast.net (qmta04.emeryville.ca.mail.comcast.net [76.96.30.40]) by core3.amsl.com (Postfix) with ESMTP id 6D0583A6955 for ; Wed, 25 Nov 2009 13:12:37 -0800 (PST) Received: from OMTA24.emeryville.ca.mail.comcast.net ([76.96.30.92]) by QMTA04.emeryville.ca.mail.comcast.net with comcast id 9Z7H1d0031zF43QA4ZCZaK; Wed, 25 Nov 2009 21:12:33 +0000 Received: from [10.36.0.42] ([98.110.239.206]) by OMTA24.emeryville.ca.mail.comcast.net with comcast id 9ZCQ1d00d4Tt8He8kZCUs2; Wed, 25 Nov 2009 21:12:37 +0000 Message-Id: <93241185-144C-461A-8FE4-4229674F1EBF@lilacglade.org> From: Margaret Wasserman To: Ladislav Lhotka In-Reply-To: <1259171047.19603.18.camel@missotis> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Wed, 25 Nov 2009 16:12:15 -0500 References: <0BA2BFF6-C05A-46FA-B8E9-AF2AEDD95665@lilacglade.org> <1259171047.19603.18.camel@missotis> X-Mailer: Apple Mail (2.936) Cc: netconf@ietf.org Subject: Re: [Netconf] xml start directive with ssh X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Nov 2009 21:12:38 -0000 Hi Lada, On Nov 25, 2009, at 12:44 PM, Ladislav Lhotka wrote: > > As a relative newcomer, I am surprised that such things can so easily > happen, given the otherwise meticulous IETF workflow. Another such > mishap was the terminating sequence "]]>]]>" - from the mailing list > archive, it seems there was a strong agreement in the WG, but on > something completely different, namely on using processing instruction > for this purpose. But this probably cannot be undone any more. > The ']]>]]>' terminating sequence was in the document from an early version, including the versions that went through Working Group LC and IETF LC. Margaret From MARKSCOT@nortel.com Wed Nov 25 14:01:41 2009 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 64F533A67B1; Wed, 25 Nov 2009 14:01:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.998 X-Spam-Level: X-Spam-Status: No, score=-5.998 tagged_above=-999 required=5 tests=[AWL=-0.599, BAYES_00=-2.599, J_CHICKENPOX_64=0.6, J_CHICKENPOX_65=0.6, RCVD_IN_DNSWL_MED=-4] 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 iDIFcZqHciCP; Wed, 25 Nov 2009 14:01:40 -0800 (PST) Received: from zrtps0kp.nortel.com (zrtps0kp.nortel.com [47.140.192.56]) by core3.amsl.com (Postfix) with ESMTP id 04D0B3A6B4E; Wed, 25 Nov 2009 14:01:39 -0800 (PST) Received: from zcarhxm2.corp.nortel.com (zcarhxm2.corp.nortel.com [47.129.230.99]) by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id nAPM0vm01800; Wed, 25 Nov 2009 22:00:57 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 25 Nov 2009 17:00:23 -0500 Message-ID: <713043CE8B8E1348AF3C546DBE02C1B41B542E18@zcarhxm2.corp.nortel.com> In-Reply-To: <4B0B1739.7090502@netconfcentral.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Netconf] YANG module naming conventions Thread-Index: AcpskvyjY54S3SsSR9WQTDWVCsKZugBhYx/g References: <713043CE8B8E1348AF3C546DBE02C1B41B48EB78@zcarhxm2.corp.nortel.com> <20091123215203.GA9240@elstar.local><20091124.000000.152719236.mbj@tail-f.com> <4B0B1739.7090502@netconfcentral.com> From: "Mark Scott" To: "Andy Bierman" , "Martin Bjorklund" Cc: netconf@ietf.org, netmod@ietf.org Subject: Re: [Netconf] YANG module naming conventions X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Nov 2009 22:01:41 -0000 I agree we don't need to align the top-level container - and will keep /netconf-state/. I also dislike the redundancy and will update the namespace to 'urn:ietf:params:xml:ns:yang:netconf-monitoring'. - maybe update the yang usage guidelines accordingly? Mark "The author works for Telefonaktiebolaget L M Ericsson ("Ericsson"), who is solely responsible for this email and its contents. All inquiries regarding this email should be addressed to Ericsson. Nortel has provided the use of the nortel.com domain to Ericsson in connection with this email solely for the purpose of connectivity and Nortel Networks has no liability for the email or its contents. The web site for Ericsson is www.ericsson.com." -----Original Message----- From: netconf-bounces@ietf.org [mailto:netconf-bounces@ietf.org] On Behalf Of Andy Bierman Sent: Monday, November 23, 2009 6:14 PM To: Martin Bjorklund Cc: netconf@ietf.org; netmod@ietf.org Subject: Re: [Netconf] YANG module naming conventions Martin Bjorklund wrote: > Hi, >=20 > Juergen Schoenwaelder wrote: >> On Mon, Nov 23, 2009 at 10:29:42PM +0100, Mark Scott wrote: >> >>> 4. Top-level container change from ?netconf-state? to >>> ?ietf-netconf-monitoring? >>> The rationale for these changes is consistency and alignment with >>> the yang module usage guidelines (see >>> http://tools.ietf.org/html/draft-ietf-netmod-yang-usage-02). >> I fail to find the guideline in netmod-yang-usage-02 that leads to a >> toplevel name like ietf-netconf-monitoring. I am not saying its wrong >> just that I do not understand the pointer to netmod-yang-usage-02. >=20 > I also noted this, and we had this discussion some time ago. At this > point, I don't think we should change it from netconf-state. >=20 I agree. I am not sure if there is still a guideline that says the top-level container should be the same as the module name. This is not really needed. The module name is not a QName so it needs special naming considerations. The top-level element is a QName and there are no naming collisions to worry about (because the namespace URI was picked to be globally unique.) >> I guess I am missing a plan for a general strategy. If we have an IETF >> protocol 'foo', do we expect YANG modules such as: >> >> YANG module YANG toplevel YANG contents >> >> ietf-foo-monitoring ietf-foo-monitoring config false objects >> ietf-foo-config ietf-foo-config config true objects >> ietf-foo - typedefs, groupings, rpcs >> >> Do we also allow / expect the following: >> >> ietf-foo-types - typedefs, groupings >> ietf-foo-ops - operations >=20 > Hopefully not... >=20 > Looking at the netconf case, I think everything could be under > 'netconf'. But not in the urn:...:ietf-netconf-monitoring namespace. >=20 We went though this issue awhile back. one container was config=3Dtrue and the other was config=3Dfalse. So one was renamed to netconf-state instead of augmenting the 4741 netconf node. > Maybe it would be better to use a more generic namespace for netconf > state and monitoring, and put monitoring in its own submodule(s) and > config in other submodule(s). >=20 >> Is the namespace always going to be >> urn:ietf:params:xml:ns:yang:$MODULE-NAME[:DRAFT-$VERSION]? >=20 > It is slightly redundant, since the $MODULE-NAME is on the form > 'ietf-NAME'. I think >=20 > urn:ietf:params:xml:ns:yang:netconf-monitoring >=20 > would be fine. >=20 >=20 >> Should ietf-foo-monitoring be in general ietf-foo-state or do we have >> yet separate modules to report operational state? Perhaps the answer >> to all this is we do not know - but I thought I at least bring up the >> question so we don't do things by accident. >> >> /js >> >> PS: I am CCing NETMOD since this is mostly an YANG issue. Further >> discussion should likely stay in NETMOD, assuming the NETCONF >> monitoring people are on NETMOD as well. >=20 > I think you forgot that, so I'm doing it now. >=20 >=20 > /martin Andy _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From randy_presuhn@mindspring.com Wed Nov 25 19:21:23 2009 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7029A3A696A; Wed, 25 Nov 2009 19:21:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.369 X-Spam-Level: X-Spam-Status: No, score=-0.369 tagged_above=-999 required=5 tests=[AWL=-0.370, BAYES_50=0.001] 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 egDktmPBVe3R; Wed, 25 Nov 2009 19:21:22 -0800 (PST) Received: from elasmtp-mealy.atl.sa.earthlink.net (elasmtp-mealy.atl.sa.earthlink.net [209.86.89.69]) by core3.amsl.com (Postfix) with ESMTP id B58193A6877; Wed, 25 Nov 2009 19:21:22 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=ahA3rWpxNd575LLzondUA62UhDO5d1slDJH/D5ExswAgtTHWcpzhGNVdPVDfh6RW; h=Received:Message-ID:From:To:Cc:References:Subject:Date:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Priority:X-MSMail-Priority:X-Mailer:X-MimeOLE:X-ELNK-Trace:X-Originating-IP; Received: from [99.41.53.116] (helo=oemcomputer) by elasmtp-mealy.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1NDUuz-0003fv-Ew; Wed, 25 Nov 2009 22:21:17 -0500 Message-ID: <001801ca6e47$ab53a700$6801a8c0@oemcomputer> From: "Randy Presuhn" To: References: <713043CE8B8E1348AF3C546DBE02C1B41B48EB78@zcarhxm2.corp.nortel.com> <20091123215203.GA9240@elstar.local><20091124.000000.152719236.mbj@tail-f.com><4B0B1739.7090502@netconfcentral.com> <713043CE8B8E1348AF3C546DBE02C1B41B542E18@zcarhxm2.corp.nortel.com> Date: Wed, 25 Nov 2009 19:22:21 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-ELNK-Trace: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d8881afdcb5313ff34f9306e75ccec835930d6608cdc1eb2cbb3350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 99.41.53.116 Cc: netmod@ietf.org Subject: Re: [Netconf] YANG module naming conventions X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Nov 2009 03:21:23 -0000 Hi - > From: "Mark Scott" > To: "Andy Bierman" ; "Martin Bjorklund" > Cc: ; > Sent: Wednesday, November 25, 2009 2:00 PM > Subject: Re: [Netconf] YANG module naming conventions ... > "The author works for Telefonaktiebolaget L M Ericsson ("Ericsson"), who > is solely responsible for this email and its contents. All inquiries ... If the "who" above refers to "Ericsson" (the only way the sentence is grammatical), then it's not clear how this fits in with IETF process, which presumes participation by individuals rather than corporations. Is this yet another example of auto-generated text which should simply be ignored? Randy From lhotka@cesnet.cz Thu Nov 26 04:45:36 2009 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A9AD93A6925 for ; Thu, 26 Nov 2009 04:45:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.25 X-Spam-Level: X-Spam-Status: No, score=-1.25 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904] 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 u9qwq+C9GlIr for ; Thu, 26 Nov 2009 04:45:36 -0800 (PST) Received: from office2.cesnet.cz (office2.cesnet.cz [195.113.144.244]) by core3.amsl.com (Postfix) with ESMTP id D95933A67B8 for ; Thu, 26 Nov 2009 04:45:35 -0800 (PST) Received: from [147.229.65.102] (p358.fei.wifi.vutbr.cz [147.229.65.102]) by office2.cesnet.cz (Postfix) with ESMTP id 16F85D80095; Thu, 26 Nov 2009 13:45:28 +0100 (CET) From: Ladislav Lhotka To: Margaret Wasserman In-Reply-To: <93241185-144C-461A-8FE4-4229674F1EBF@lilacglade.org> References: <0BA2BFF6-C05A-46FA-B8E9-AF2AEDD95665@lilacglade.org> <1259171047.19603.18.camel@missotis> <93241185-144C-461A-8FE4-4229674F1EBF@lilacglade.org> Content-Type: text/plain; charset="UTF-8" Organization: CESNET Date: Thu, 26 Nov 2009 13:45:24 +0100 Message-ID: <1259239524.2308.10.camel@nomad> Mime-Version: 1.0 X-Mailer: Evolution 2.28.1 Content-Transfer-Encoding: 7bit Cc: netconf@ietf.org Subject: Re: [Netconf] xml start directive with ssh X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Nov 2009 12:45:36 -0000 On St, 2009-11-25 at 16:12 -0500, Margaret Wasserman wrote: > Hi Lada, > > On Nov 25, 2009, at 12:44 PM, Ladislav Lhotka wrote: > > > > As a relative newcomer, I am surprised that such things can so easily > > happen, given the otherwise meticulous IETF workflow. Another such > > mishap was the terminating sequence "]]>]]>" - from the mailing list > > archive, it seems there was a strong agreement in the WG, but on > > something completely different, namely on using processing instruction > > for this purpose. But this probably cannot be undone any more. > > > > The ']]>]]>' terminating sequence was in the document from an early > version, including the versions that went through Working Group LC and > IETF LC. Hmm, I only found the thread started by this Andy's message: http://www.ops.ietf.org/lists/netconf/netconf.2003/msg00988.html This thread only discusses (and its modifications) as the EOM marker, I couldn't find any proposal of using "]]>]]>" instead. Lada > > Margaret > -- Ladislav Lhotka, CESNET PGP Key ID: E74E8C0C From mrw@lilacglade.org Thu Nov 26 06:13:49 2009 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8DD5D3A6972 for ; Thu, 26 Nov 2009 06:13:49 -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 mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ttcbj7JP7dq9 for ; Thu, 26 Nov 2009 06:13:48 -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 57CB728C10A for ; Thu, 26 Nov 2009 06:13:47 -0800 (PST) Received: from OMTA21.westchester.pa.mail.comcast.net ([76.96.62.72]) by QMTA09.westchester.pa.mail.comcast.net with comcast id 9q5D1d0011ZXKqc59qDjp3; Thu, 26 Nov 2009 14:13:43 +0000 Received: from [10.36.0.42] ([98.110.239.206]) by OMTA21.westchester.pa.mail.comcast.net with comcast id 9qMP1d0094Tt8He3hqMV2h; Thu, 26 Nov 2009 14:21:46 +0000 Message-Id: <786DAED6-BCBF-4E1F-B646-6EDADB27BE8A@lilacglade.org> From: Margaret Wasserman To: Ladislav Lhotka In-Reply-To: <1259239524.2308.10.camel@nomad> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Thu, 26 Nov 2009 09:13:14 -0500 References: <0BA2BFF6-C05A-46FA-B8E9-AF2AEDD95665@lilacglade.org> <1259171047.19603.18.camel@missotis> <93241185-144C-461A-8FE4-4229674F1EBF@lilacglade.org> <1259239524.2308.10.camel@nomad> X-Mailer: Apple Mail (2.936) Cc: netconf@ietf.org Subject: Re: [Netconf] xml start directive with ssh X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Nov 2009 14:13:49 -0000 Hi Lada, The decision to use ']]>]]>' as the end-of-message marker was made at the IETF 59 in Seoul, Korea (Feb/March, 2004), as indicated in the minutes from that meeting: http://www.ietf.org/proceedings/59/ The chairs communicated their consensus call on this issue to the list (along with consensus calls for a number of other open issues) on March 11, 2004, in this message: http://www.ops.ietf.org/lists/netconf/netconf.2004/msg00218.html Since there was no objection to that consensus call, it was added to the next version of the document (draft-ietf-netconf-ssh-01.txt published in May, 2004), and it has been in the document ever since. Margaret On Nov 26, 2009, at 7:45 AM, Ladislav Lhotka wrote: > On St, 2009-11-25 at 16:12 -0500, Margaret Wasserman wrote: >> Hi Lada, >> >> On Nov 25, 2009, at 12:44 PM, Ladislav Lhotka wrote: >>> >>> As a relative newcomer, I am surprised that such things can so >>> easily >>> happen, given the otherwise meticulous IETF workflow. Another such >>> mishap was the terminating sequence "]]>]]>" - from the mailing list >>> archive, it seems there was a strong agreement in the WG, but on >>> something completely different, namely on using processing >>> instruction >>> for this purpose. But this probably cannot be undone any more. >>> >> >> The ']]>]]>' terminating sequence was in the document from an early >> version, including the versions that went through Working Group LC >> and >> IETF LC. > > Hmm, I only found the thread started by this Andy's message: > http://www.ops.ietf.org/lists/netconf/netconf.2003/msg00988.html > > This thread only discusses (and its modifications) as the EOM > marker, I couldn't find any proposal of using "]]>]]>" instead. > > Lada > >> >> Margaret >> > > > -- > Ladislav Lhotka, CESNET > PGP Key ID: E74E8C0C > From lhotka@cesnet.cz Fri Nov 27 01:10:40 2009 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A97053A68E8 for ; Fri, 27 Nov 2009 01:10:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.204 X-Spam-Level: X-Spam-Status: No, score=-0.204 tagged_above=-999 required=5 tests=[AWL=-0.813, BAYES_20=-0.74, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904] 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 UoxgfaJ2HYGC for ; Fri, 27 Nov 2009 01:10:39 -0800 (PST) Received: from office2.cesnet.cz (office2.cesnet.cz [195.113.144.244]) by core3.amsl.com (Postfix) with ESMTP id 78F1D3A677D for ; Fri, 27 Nov 2009 01:10:39 -0800 (PST) Received: from [172.29.2.201] (asus-gx.lhotka.cesnet.cz [195.113.161.161]) by office2.cesnet.cz (Postfix) with ESMTP id 003C5D80095; Fri, 27 Nov 2009 10:10:32 +0100 (CET) From: Ladislav Lhotka To: Margaret Wasserman In-Reply-To: <786DAED6-BCBF-4E1F-B646-6EDADB27BE8A@lilacglade.org> References: <0BA2BFF6-C05A-46FA-B8E9-AF2AEDD95665@lilacglade.org> <1259171047.19603.18.camel@missotis> <93241185-144C-461A-8FE4-4229674F1EBF@lilacglade.org> <1259239524.2308.10.camel@nomad> <786DAED6-BCBF-4E1F-B646-6EDADB27BE8A@lilacglade.org> Content-Type: text/plain; charset="UTF-8" Organization: CESNET Date: Fri, 27 Nov 2009 10:10:31 +0100 Message-ID: <1259313031.2102.13.camel@missotis> Mime-Version: 1.0 X-Mailer: Evolution 2.28.1 Content-Transfer-Encoding: 8bit Cc: netconf@ietf.org Subject: Re: [Netconf] xml start directive with ssh X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Nov 2009 09:10:40 -0000 Hi, Margaret, thank you for the clarification, Google search didn̈́'t return these documents, also because the sequence was "misspelled" in the ML message. Lada Margaret Wasserman píše v Čt 26. 11. 2009 v 09:13 -0500: > Hi Lada, > > The decision to use ']]>]]>' as the end-of-message marker was made at > the IETF 59 in Seoul, Korea (Feb/March, 2004), as indicated in the > minutes from that meeting: > > http://www.ietf.org/proceedings/59/ > > The chairs communicated their consensus call on this issue to the list > (along with consensus calls for a number of other open issues) on > March 11, 2004, in this message: > > http://www.ops.ietf.org/lists/netconf/netconf.2004/msg00218.html > > Since there was no objection to that consensus call, it was added to > the next version of the document (draft-ietf-netconf-ssh-01.txt > published in May, 2004), and it has been in the document ever since. > > Margaret > > > On Nov 26, 2009, at 7:45 AM, Ladislav Lhotka wrote: > > > On St, 2009-11-25 at 16:12 -0500, Margaret Wasserman wrote: > >> Hi Lada, > >> > >> On Nov 25, 2009, at 12:44 PM, Ladislav Lhotka wrote: > >>> > >>> As a relative newcomer, I am surprised that such things can so > >>> easily > >>> happen, given the otherwise meticulous IETF workflow. Another such > >>> mishap was the terminating sequence "]]>]]>" - from the mailing list > >>> archive, it seems there was a strong agreement in the WG, but on > >>> something completely different, namely on using processing > >>> instruction > >>> for this purpose. But this probably cannot be undone any more. > >>> > >> > >> The ']]>]]>' terminating sequence was in the document from an early > >> version, including the versions that went through Working Group LC > >> and > >> IETF LC. > > > > Hmm, I only found the thread started by this Andy's message: > > http://www.ops.ietf.org/lists/netconf/netconf.2003/msg00988.html > > > > This thread only discusses (and its modifications) as the EOM > > marker, I couldn't find any proposal of using "]]>]]>" instead. > > > > Lada > > > >> > >> Margaret > >> > > > > > > -- > > Ladislav Lhotka, CESNET > > PGP Key ID: E74E8C0C > > > -- Ladislav Lhotka, CESNET PGP Key ID: E74E8C0C From j.schoenwaelder@jacobs-university.de Fri Nov 27 01:18:57 2009 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 62E2E3A69E7; Fri, 27 Nov 2009 01:18:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.113 X-Spam-Level: X-Spam-Status: No, score=-1.113 tagged_above=-999 required=5 tests=[AWL=-0.723, BAYES_20=-0.74, HELO_EQ_DE=0.35] 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 IhYZvlwYfsuQ; Fri, 27 Nov 2009 01:18:56 -0800 (PST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 1AA633A677D; Fri, 27 Nov 2009 01:18:56 -0800 (PST) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 0ACBFC000D; Fri, 27 Nov 2009 10:18:50 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius2.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id bdGdkYB+iLcF; Fri, 27 Nov 2009 10:18:49 +0100 (CET) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 35EC1C0009; Fri, 27 Nov 2009 10:18:48 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 0FE24E374B5; Fri, 27 Nov 2009 10:18:46 +0100 (CET) Date: Fri, 27 Nov 2009 10:18:46 +0100 From: Juergen Schoenwaelder To: Mark Scott Message-ID: <20091127091846.GA12557@elstar.local> Mail-Followup-To: Mark Scott , Andy Bierman , Martin Bjorklund , "netconf@ietf.org" , "netmod@ietf.org" References: <713043CE8B8E1348AF3C546DBE02C1B41B48EB78@zcarhxm2.corp.nortel.com> <20091123215203.GA9240@elstar.local> <20091124.000000.152719236.mbj@tail-f.com> <4B0B1739.7090502@netconfcentral.com> <713043CE8B8E1348AF3C546DBE02C1B41B542E18@zcarhxm2.corp.nortel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <713043CE8B8E1348AF3C546DBE02C1B41B542E18@zcarhxm2.corp.nortel.com> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: "netconf@ietf.org" , "netmod@ietf.org" Subject: Re: [Netconf] [netmod] YANG module naming conventions X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Nov 2009 09:18:57 -0000 On Wed, Nov 25, 2009 at 11:00:23PM +0100, Mark Scott wrote: > I agree we don't need to align the top-level container - and will keep > /netconf-state/. > > I also dislike the redundancy and will update the namespace to > 'urn:ietf:params:xml:ns:yang:netconf-monitoring'. > - maybe update the yang usage guidelines accordingly? If there is agreement to not carry the module name in the URN, we should indeed document that agreement and all modules should stick to the documented agreement. So there is no "maybe". And yes, "ietf" is redundant but then special casing the removal of a module name prefix for generating the URN does not really seem to make things simpler. For me, urn:ietf:params:xml:ns:yang:$MODULENAME is simpler than urn:ietf:params:xml:ns:yang:`echo $MODULENAME | sed s/^ietf-//` and this special casing will also lead to subsequent questions about how we deal with modules coming from other RFC streams. For me, simply copying the module name after the urn:ietf:params:xml:ns:yang: prefix is as simple as it can get (I can even get the module name from the namespace in the payload with straight cut'n paste). /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From andy@netconfcentral.com Sat Nov 28 04:07:02 2009 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 675033A67EC for ; Sat, 28 Nov 2009 04:07:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.469 X-Spam-Level: X-Spam-Status: No, score=-2.469 tagged_above=-999 required=5 tests=[AWL=0.129, BAYES_00=-2.599, UNPARSEABLE_RELAY=0.001] 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 aV2bYbTRNRhD for ; Sat, 28 Nov 2009 04:07:01 -0800 (PST) Received: from smtp101.sbc.mail.mud.yahoo.com (smtp101.sbc.mail.mud.yahoo.com [68.142.198.200]) by core3.amsl.com (Postfix) with SMTP id 492303A67B0 for ; Sat, 28 Nov 2009 04:07:01 -0800 (PST) Received: (qmail 80544 invoked from network); 28 Nov 2009 12:06:52 -0000 Received: from adsl-67-125-158-117.dsl.irvnca.pacbell.net (andy@67.125.158.117 with plain) by smtp101.sbc.mail.mud.yahoo.com with SMTP; 28 Nov 2009 04:06:51 -0800 PST X-Yahoo-SMTP: Z6xhxCCswBAlhcxjVNwaQtp4EKpLdTUUf5Nx_pGy81o- X-YMail-OSG: yWdSpRYVM1l6P64d5aP.MJ6iad5BtU3bTWg_pvcABpXyoIkwg_YXaw1aBKEgUCQkoK12SKgjs6phgRWDvea2b_I5P1zxqd6Cdc4GaTYbrzwz7bCMmmpmiArl4VLI3h6iYuoD.wlxUBQLYbfz75I5QdjBzhWZzY6TT8mv.60jE6QWHDeNSlWg0pOfkKh4kb_2LmJaZp23KlDOhY73_QDHH5RECl1xod1rxDYkN4RxIHe3G.OQismcHyNYyw4njLOkJcEZ0hw.bH7q93ykXio9UbRJNItnznhmtK4wXA-- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4B1111E4.2000407@netconfcentral.com> Date: Sat, 28 Nov 2009 04:04:52 -0800 From: Andy Bierman User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: Randy Presuhn References: <200911201840.nAKIeAo9087472@idle.juniper.net> <001b01ca6a16$dca05400$6801a8c0@oemcomputer> In-Reply-To: <001b01ca6a16$dca05400$6801a8c0@oemcomputer> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: netconf@ietf.org Subject: Re: [Netconf] Consensus call: With-Defaults as SHOULD in 4741bis X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Nov 2009 12:07:02 -0000 Randy Presuhn wrote: > Hi - > >> From: "Phil Shafer" >> To: "Ersue, Mehmet (NSN - DE/Munich)" >> Cc: "David Partain" ; ; "NETMOD Working Group" ; "Kessens, David > (NSN - US/Atlanta)" >> Sent: Friday, November 20, 2009 10:40 AM >> Subject: Re: [Netconf] Consensus call: With-Defaults as SHOULD in 4741bis > ... >> I do not want W-D to be a SHOULD requirement since it is not required >> for the proper operation of a NETCONF server. > > If somethine is "required for ... proper operation" then the correct keyword > is MUST, not SHOULD. See (1) in RFC 2119. > >> We have managed >> without it for a long long time and I do not see it as vital. Heck, >> there's no requirement in NETCONF for the data model to even _have_ >> default values. 4741 current says nothing about the data model's >> contents and says absolutely nothing about default values. I don't >> see a convincing reason why this should change. > > RFC 2119 says "3. SHOULD This word, or the adjective > "RECOMMENDED", mean that there may exist valid reasons > in particular circumstances to ignore a particular item, but the full > implications must be understood and carefully weighed before > choosing a different course." > > It seems to me that "SHOULD" is indeed the correct keyword for > this case. I can't see aother way of applying RFC 2119 here. > +1 > Randy Andy From david.partain@ericsson.com Mon Nov 30 06:00:50 2009 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0C4C43A6811; Mon, 30 Nov 2009 06:00:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] 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 01LKVu-twpMY; Mon, 30 Nov 2009 06:00:49 -0800 (PST) Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by core3.amsl.com (Postfix) with ESMTP id E5E213A676A; Mon, 30 Nov 2009 06:00:48 -0800 (PST) X-AuditID: c1b4fb3e-b7b33ae0000045f9-33-4b13d00871c0 Received: from esealmw127.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw4.ericsson.se (Symantec Mail Security) with SMTP id 14.1E.17913.800D31B4; Mon, 30 Nov 2009 15:00:40 +0100 (CET) Received: from esealmw127.eemea.ericsson.se ([153.88.254.175]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Mon, 30 Nov 2009 15:00:40 +0100 Received: from selic023.ki.sw.ericsson.se ([147.214.22.154]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Mon, 30 Nov 2009 15:00:40 +0100 From: David Partain Organization: Ericsson AB To: netconf@ietf.org, "NETMOD Working Group" Date: Mon, 30 Nov 2009 15:00:53 +0100 User-Agent: KMail/1.9.10 References: <80A0822C5E9A4440A5117C2F4CD36A641A0C02@DEMUEXC006.nsn-intra.net> In-Reply-To: <80A0822C5E9A4440A5117C2F4CD36A641A0C02@DEMUEXC006.nsn-intra.net> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200911301500.53656.david.partain@ericsson.com> X-OriginalArrivalTime: 30 Nov 2009 14:00:40.0627 (UTC) FILETIME=[802AE030:01CA71C5] X-Brightmail-Tracker: AAAAAA== Subject: Re: [Netconf] Consensus call: With-Defaults as SHOULD in 4741bis X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Nov 2009 14:00:50 -0000 Greetings, > If you agree with the conclusion having 'with-defaults' > as SHOULD to implement in 4741bis please state so. +1 or... Yes, I agree with this conclusion. Cheers, David From MARKSCOT@nortel.com Mon Nov 30 07:58:30 2009 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EB8C93A6A95; Mon, 30 Nov 2009 07:58:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.299 X-Spam-Level: X-Spam-Status: No, score=-6.299 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 PqoYYCwO7kM2; Mon, 30 Nov 2009 07:58:30 -0800 (PST) Received: from zrtps0kp.nortel.com (zrtps0kp.nortel.com [47.140.192.56]) by core3.amsl.com (Postfix) with ESMTP id CA75D3A6939; Mon, 30 Nov 2009 07:58:29 -0800 (PST) Received: from zcarhxm2.corp.nortel.com (zcarhxm2.corp.nortel.com [47.129.230.99]) by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id nAUFwHL09587; Mon, 30 Nov 2009 15:58:17 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 30 Nov 2009 10:57:30 -0500 Message-ID: <713043CE8B8E1348AF3C546DBE02C1B41B5E4198@zcarhxm2.corp.nortel.com> In-Reply-To: <200911301500.53656.david.partain@ericsson.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [netmod] Consensus call: With-Defaults as SHOULD in 4741bis Thread-Index: AcpxxYyYdvyNHpxdQlKdHmV8md7GyAAD/RuQ References: <80A0822C5E9A4440A5117C2F4CD36A641A0C02@DEMUEXC006.nsn-intra.net> <200911301500.53656.david.partain@ericsson.com> From: "Mark Scott" To: "David Partain" , , "NETMOD Working Group" Subject: Re: [Netconf] [netmod] Consensus call: With-Defaults as SHOULD in 4741bis X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Nov 2009 15:58:31 -0000 +1 in favour of SHOULD. Mark "The author works for Telefonaktiebolaget L M Ericsson ("Ericsson"), who is solely responsible for this email and its contents. All inquiries regarding this email should be addressed to Ericsson. Nortel has provided the use of the nortel.com domain to Ericsson in connection with this email solely for the purpose of connectivity and Nortel Networks has no liability for the email or its contents. The web site for Ericsson is www.ericsson.com." -----Original Message----- From: netmod-bounces@ietf.org [mailto:netmod-bounces@ietf.org] On Behalf Of David Partain Sent: Monday, November 30, 2009 9:01 AM To: netconf@ietf.org; NETMOD Working Group Subject: Re: [netmod] Consensus call: With-Defaults as SHOULD in 4741bis Greetings, > If you agree with the conclusion having 'with-defaults' > as SHOULD to implement in 4741bis please state so. +1=20 or... Yes, I agree with this conclusion. Cheers, David _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From MARKSCOT@nortel.com Mon Nov 30 10:22:19 2009 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 751723A6AAD; Mon, 30 Nov 2009 10:22:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.399 X-Spam-Level: X-Spam-Status: No, score=-6.399 tagged_above=-999 required=5 tests=[AWL=0.200, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 J4dIw3KtleQk; Mon, 30 Nov 2009 10:22:18 -0800 (PST) Received: from zrtps0kp.nortel.com (zrtps0kp.nortel.com [47.140.192.56]) by core3.amsl.com (Postfix) with ESMTP id 466073A693C; Mon, 30 Nov 2009 10:22:18 -0800 (PST) Received: from zcarhxm2.corp.nortel.com (zcarhxm2.corp.nortel.com [47.129.230.99]) by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id nAUIM7L23619; Mon, 30 Nov 2009 18:22:08 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 30 Nov 2009 13:21:58 -0500 Message-ID: <713043CE8B8E1348AF3C546DBE02C1B41B64793A@zcarhxm2.corp.nortel.com> In-Reply-To: <001801ca6e47$ab53a700$6801a8c0@oemcomputer> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Netconf] YANG module naming conventions Thread-Index: AcpuR5tt4t3XlEnmSE2ZMomC/oyPoADoDd8g References: <713043CE8B8E1348AF3C546DBE02C1B41B48EB78@zcarhxm2.corp.nortel.com> <20091123215203.GA9240@elstar.local><20091124.000000.152719236.mbj@tail-f.com><4B0B1739.7090502@netconfcentral.com><713043CE8B8E1348AF3C546DBE02C1B41B542E18@zcarhxm2.corp.nortel.com> <001801ca6e47$ab53a700$6801a8c0@oemcomputer> From: "Mark Scott" To: "Randy Presuhn" , Cc: netmod@ietf.org Subject: Re: [Netconf] YANG module naming conventions X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Nov 2009 18:22:19 -0000 Randy, As a result of the acquisition of certain Nortel assets by Ericsson all emails originating from associated accounts must have this (exact) text appended. Please ignore the text. cheers, Mark "The author works for Telefonaktiebolaget L M Ericsson ("Ericsson"), who is solely responsible for this email and its contents. All inquiries regarding this email should be addressed to Ericsson. Nortel has provided the use of the nortel.com domain to Ericsson in connection with this email solely for the purpose of connectivity and Nortel Networks has no liability for the email or its contents. The web site for Ericsson is www.ericsson.com." -----Original Message----- From: netconf-bounces@ietf.org [mailto:netconf-bounces@ietf.org] On Behalf Of Randy Presuhn Sent: Wednesday, November 25, 2009 10:22 PM To: netconf@ietf.org Cc: netmod@ietf.org Subject: Re: [Netconf] YANG module naming conventions Hi - =20 > From: "Mark Scott" > To: "Andy Bierman" ; "Martin Bjorklund" > Cc: ; > Sent: Wednesday, November 25, 2009 2:00 PM > Subject: Re: [Netconf] YANG module naming conventions ... > "The author works for Telefonaktiebolaget L M Ericsson ("Ericsson"), who > is solely responsible for this email and its contents. All inquiries ... If the "who" above refers to "Ericsson" (the only way the sentence is grammatical), then it's not clear how this fits in with IETF process, which presumes participation by individuals rather than corporations. Is this yet another example of auto-generated text which should simply be ignored? Randy _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From MARKSCOT@nortel.com Mon Nov 30 11:59:39 2009 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F1B883A68F1 for ; Mon, 30 Nov 2009 11:59:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.149 X-Spam-Level: X-Spam-Status: No, score=-6.149 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, J_CHICKENPOX_26=0.6, RCVD_IN_DNSWL_MED=-4] 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 nYliQO5vHnQL for ; Mon, 30 Nov 2009 11:59:38 -0800 (PST) Received: from zrtps0kp.nortel.com (zrtps0kp.nortel.com [47.140.192.56]) by core3.amsl.com (Postfix) with ESMTP id 039E03A68C9 for ; Mon, 30 Nov 2009 11:59:37 -0800 (PST) Received: from zcarhxm2.corp.nortel.com (zcarhxm2.corp.nortel.com [47.129.230.99]) by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id nAUJxOL19570; Mon, 30 Nov 2009 19:59:24 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 30 Nov 2009 14:59:00 -0500 Message-ID: <713043CE8B8E1348AF3C546DBE02C1B41B647BE0@zcarhxm2.corp.nortel.com> In-Reply-To: <20091102211232.GA4455@elstar.local> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Netconf] draft-ietf-netconf-monitoring-09 last call comments fromjs Thread-Index: AcpcAVeZxF9vZCSnQEGNEgj1KxUSVQJ3heHw References: <085091CB2CA14E4B8B163FFC37C84E9D1A9F69CD@zcarhxm0.corp.nortel.com><80A0822C5E9A4440A5117C2F4CD36A64031460@DEMUEXC006.nsn-intra.net> <20091102211232.GA4455@elstar.local> From: "Mark Scott" To: "Juergen Schoenwaelder" Cc: netconf@ietf.org Subject: Re: [Netconf] draft-ietf-netconf-monitoring-09 last call comments fromjs X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Nov 2009 19:59:40 -0000 Juergen, Thank you for your detailed comments. v10 addresses these per responses below and will be posted today. If I have missed anything or you see further changes required please let me know. Mark Comment 1: ---------- : [...] The : capabilities of a NETCONF server may change over time. However, once : a NETCONF server has announced its capabilities in the : message, the capabilities for that session MUST NOT change. A server : MUST reply with a 'capabilities-changed' error if the client sends a : request which is affected by a modified capability. A server MAY : choose to send 'capabilities-changed' as the response to any request : other than if its capabilities has changed. It seems to me that it is not the job of the monitoring document to establish rules how NETCONF works. I suggest to remove this text and to include such text in RFC 4741bis instead. UPDATE: text has been rewritten in monitoring-10 and have asked Martin to ensure 4741bis covers this instead Comment 2: ---------- : Through updated monitoring data NETCONF clients can adjust their : capabilities throughout a session. I wonder how this is supposed to work. Once the server starts to generate 'capabilities-changed' errors, I need an explicit resync action - reading the monitoring data can hardly be sufficient to declare that things are not synchronized again. RESPONSE: When this was discussed earlier the agreement was to cover this in 4741bis. Per last notes I had on this one the intent is to add something of this nature to 4741bis: "The agent MUST return the capability-changed error (except safe RPCs ***) unless the session has invoked the operation. *** close-session, kill-session, get-schema, turn-off-capability-changed-error, lock, unlock, partial-lock, partial-unlock, discard-changes" With respect to re-synch a client which leaves the error enabled is expected to close their existing session and establish a new one when they see this error. This was chosen in favour of putting onus on the server to track per session schema synch information. I expect this to be covered in 4741bis. A client which opts to disable the error has to have its own means to detect loss of synch and implement its own method to re-synch. This will likely be implementation specific. Comment 3: ---------- : Schema: A machine readable data model definition. The schema is : independent of which data modeling language is used for the data : model. I have trouble to understand the second sentence. Every machine readable data model is written in a specific format. So how can the schema be format specific and at the same time independent? Perhaps the second sentence should just be removed. UPDATE: Second sentence has been removed. Comment 4: ---------- : The following data allows a NETCONF client to monitor both the : NETCONF server itself and the associated network device operational : data. I wonder what "associated network device operational data" means. I thought the YANG model only reports NETCONF server operational state and statistics. UPDATE: Leftover from earlier versions/intent to include non-NETCONF=20 Data (e.g. CLI session data, sysUpTime). Reworded to be NETCONF specific. Comment 5: ---------- : To provide clients the ability to manage locked resources lock : information is provided for each ConfigurationDataStore instance. I have no clue what this ConfigurationDataStore instance is. UPDATE: Reference to XSD type in earlier draft. Replaced with text Indicating this information is contained in /netconf-state/datastores list entries. Comment 6: ---------- : For YANG data models, the format is one of "yang" or "yin". I am concerned about interoperability here. I prefer that the "yang" format is required and "yin" can be provided optionally. Otherwise, you require that all management applications have two parsers instead of one. UPDATE: Updated. Proposing YANG as required and YIN is optional in the new Text. Comment 7: ---------- : A schema entry may be located on a network device (eg: xs:anyURI), : a remote file system (eg: xs:string reference to file system for : ftp retrieval) or available explicitly via NETCONF (xs:string : value 'NETCONF') for NETCONF servers which support the : operation. You probably want to replace the references to XSD types for consistency. UPDATE: Done. Comment 8: ---------- : For YANG data models, this is the module's namespace. If the list : entry describes a submodule, this field contains the namespace of : the module to which the submodule belongs. This text seems misplaced since I believe this has nothing to do with the location. UPDATE: Fixed. It belonged under namespace. : Includes session specific data for NETCONF management sessions. : The session list MUST include all currently active NETCONF sessions, : and MAY include other sessions as well. Comment 9: ---------- It is unclear what "other sessions" mean. If you mean "inactive" sessions or "recently closed sessions", simply say so. If you mean non NETCONF sessions, well that that kind of violates the first sentence. Please clarify. UPDATE: Reworded. References only active sessions now. =20 Comment 10: ---------- : For purposes of NETCONF management all sessions are one of: : : Known session: any session which can be managed by the : NETCONF server SHOULD be reported in this table. : : Unknown session: such sessions are not managed by the : NETCONF server and map to NETCONF session identifier 0. : These MUST be excluded from the session table as a result. I dislike the word table - XML is not tables like SMIv2. That said, I find the text confusing. What you are really saying is: Monitoring data is only provided for session with a non-zero session-id. UPDATE: Yes. Reworded to list. Comment 11: ---------- : transport (identityref, transport) : Idenfities type for each session, e.g. "netconf-ssh", : "netconf-soap", etc. Replace with "Identifies that transport for each ..." UPDATE: Reworded. Comment 12: ---------- : username (string) : If present, the username contains an identifier which can be : used to uniquely identify an individual client (human or : machine). This is likely to be implementation specific and : subject to the security requirements of the device vendor : and/or operators, e.g., an SSH user, a host RSA fingerprint : or other identifier deemed acceptable. I do not want to boil the ocean, but we will likely have to work this out in more detail later when access control is defined and we need a deterministic way to derive a username from whatever has been used for authentication. Those who follow the ISMS work will know why I have to comment on this. So take this as a warning that in the future, we will have to define much more precise ways to derive a username if we associate access control rules with user identities. RESPONSE: Valid point to raise. At present assumption is that regardless of underling security and access control a string representation should be sufficient if an implementation so chooses. It is not mandatory and=20 an implementation can choose to omit as appropriate. Comment 13: ---------- : When the schema is available on the device this operation is : used to return it via NETCONF. This conditional sentence sounds backwards. What about this: This operation can be used to retrieve a schema form the NETCONF server. UPDATE: Ok. Reworded. : module bar { : bar version 2008-06-01 yang module : contents here ... : } Comment 14: ---------- Make this legal yang by using comments: module bar { // bar version 2008-06-01 yang module // contents here ... } : module bar-types { : bar-types version 2008-06-01 yang module : contents here ... : } Make this legal yang by using comments: module bar-types { // bar-types version 2008-06-01 yang module // contents here ... } UPDATE: Done. Comment 15: ---------- : identity transport { : description : "Base identity for session types."; : } This should be "Base identity for NETCONF transports.". Please remove all mentions of "session types". UPDATE: Done. : reference "RFC 4742"; Comment 16: ---------- Replace with reference "RFC 4742: Using the NETCONF Configuration Protocol=20 over Secure SHell (SSH)"; : reference "RFC 4743"; Replace with reference "RFC 4743: Using NETCONF over the Simple Object=20 Access Protocol (SOAP)"; : reference "RFC 4744"; Replace with reference "RFC 4744: Using the NETCONF Protocol over the Blocks Extensible Exchange Protocol (BEEP)"; : reference "RFC 5539"; Replace with reference "RFC 5539: NETCONF over Transport Layer Security (TLS)"; : reference "W3C REC REC-xmlschema-1-20041028"; Replace with reference "W3C REC REC-xmlschema-1-20041028: XML Schema Part 1: Structure W3C REC REC-xmlschema-2-20041028: XML Schema Part 2: Datatypes"; : reference "ISO/IEC 19757-2"; Replace with reference "ISO/IEC 19757-2: RELAX NG"; : reference "ISO/IEC 19757-2"; Replace with reference "ISO/IEC 19757-2: RELAX NG"; UPDATE: Done. (thank you for the detailed rewording above.) Comment 17: ---------- : list partial-locks { : key lock-id; : description : "For a partial lock this is the lock id returned : in the response."; : leaf lock-id { : type uint32; : } The description like should be a description of the leaf lock-id and not the partial-locks list itself. UPDATE: Fixed. Moved existing description for lock-id and added new description for the list. : list session { : key session-id; : leaf session-id { : type session-id; : } : leaf transport { : mandatory true; : type identityref { : base transport; : } : } : leaf username { : type string; : } : leaf source-host { : type inet:host; : } Comment 18: ---------- I am badly missing description statements here. In general, it seems that many description statements leave out details that are explained in section 2. In SMIv2 land, it was considered good practice to have all normative texts in the data model so that the text is there once extracted from the RFC. I believe we should follow this practice and move most of the text from section 2.1 into description clauses. This also avoids any potential inconsistencies. leaf login-time { mandatory true; type yang:date-and-time; description "Time at which the session was established."; } UPDATE: Yang module and section 2 have been merged to make the module self describing. I have added description clauses to all elements. Please let me know if any are missing and/or are not clear. Comment 19: ---------- I am wondering why some objects are mandatory while others are not. For example, why is the login-time mandatory while the netconf-start-time is not mandatory? It is not clear to me as a reader whether there are any specific requirements on login-time that give it a special status and that do not apply to netconf-start-time. UPDATE: I've added explanations for each based on comments from the ML requesting the changes. Please feel free to comment on any which are not clearer now. Comment 20: ---------- Finally, I like to comment that I find the choice lock-type a somewhat artifical construction. I understand that a global lock and a partial lock can't exist together. Still, I would have modeled a simple global-lock container and a partial-locks list. I find this somewhat simpler to follow, also because partial locks really are a feature. (The model does not really distinguish features in general.) But perhaps this is just a style issue and not really important to agree on. RESPONSE: Leaving as is at this point. Does anyone else feel strongly about this one way or the other? /js --=20 Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From MARKSCOT@nortel.com Mon Nov 30 12:32:55 2009 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 852A73A685E; Mon, 30 Nov 2009 12:32:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.419 X-Spam-Level: X-Spam-Status: No, score=-6.419 tagged_above=-999 required=5 tests=[AWL=0.180, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 PvCDjGcGXtIh; Mon, 30 Nov 2009 12:32:54 -0800 (PST) Received: from zrtps0kp.nortel.com (zrtps0kp.nortel.com [47.140.192.56]) by core3.amsl.com (Postfix) with ESMTP id 4E0FF3A6904; Mon, 30 Nov 2009 12:32:54 -0800 (PST) Received: from zcarhxm2.corp.nortel.com (zcarhxm2.corp.nortel.com [47.129.230.99]) by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id nAUKWAL00171; Mon, 30 Nov 2009 20:32:10 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 30 Nov 2009 15:31:56 -0500 Message-ID: <713043CE8B8E1348AF3C546DBE02C1B41B647CB7@zcarhxm2.corp.nortel.com> In-Reply-To: <20091127091846.GA12557@elstar.local> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [netmod] [Netconf] YANG module naming conventions Thread-Index: AcpvQqNRW5ls22PeT5eGCYbiuwHarwCuVZIA References: <713043CE8B8E1348AF3C546DBE02C1B41B48EB78@zcarhxm2.corp.nortel.com> <20091123215203.GA9240@elstar.local> <20091124.000000.152719236.mbj@tail-f.com> <4B0B1739.7090502@netconfcentral.com> <713043CE8B8E1348AF3C546DBE02C1B41B542E18@zcarhxm2.corp.nortel.com> <20091127091846.GA12557@elstar.local> From: "Mark Scott" To: "Juergen Schoenwaelder" Cc: netconf@ietf.org, netmod@ietf.org Subject: Re: [Netconf] [netmod] YANG module naming conventions X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Nov 2009 20:32:55 -0000 Agree. No special case required and the complete module name is used in the URN (see v10). Mark "The author works for Telefonaktiebolaget L M Ericsson ("Ericsson"), who is solely responsible for this email and its contents. All inquiries regarding this email should be addressed to Ericsson. Nortel has provided the use of the nortel.com domain to Ericsson in connection with this email solely for the purpose of connectivity and Nortel Networks has no liability for the email or its contents. The web site for Ericsson is www.ericsson.com." -----Original Message----- From: Juergen Schoenwaelder [mailto:j.schoenwaelder@jacobs-university.de]=20 Sent: Friday, November 27, 2009 4:19 AM To: Scott, Mark ERICSSON (CAR:2N00) Cc: Andy Bierman; Martin Bjorklund; netconf@ietf.org; netmod@ietf.org Subject: Re: [netmod] [Netconf] YANG module naming conventions On Wed, Nov 25, 2009 at 11:00:23PM +0100, Mark Scott wrote: > I agree we don't need to align the top-level container - and will keep > /netconf-state/. >=20 > I also dislike the redundancy and will update the namespace to > 'urn:ietf:params:xml:ns:yang:netconf-monitoring'. > - maybe update the yang usage guidelines accordingly? If there is agreement to not carry the module name in the URN, we should indeed document that agreement and all modules should stick to the documented agreement. So there is no "maybe". And yes, "ietf" is redundant but then special casing the removal of a module name prefix for generating the URN does not really seem to make things simpler. For me, urn:ietf:params:xml:ns:yang:$MODULENAME is simpler than urn:ietf:params:xml:ns:yang:`echo $MODULENAME | sed s/^ietf-//` and this special casing will also lead to subsequent questions about how we deal with modules coming from other RFC streams. For me, simply copying the module name after the urn:ietf:params:xml:ns:yang: prefix is as simple as it can get (I can even get the module name from the namespace in the payload with straight cut'n paste). /js --=20 Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From root@core3.amsl.com Mon Nov 30 12:45:01 2009 Return-Path: X-Original-To: netconf@ietf.org Delivered-To: netconf@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 775E53A699C; Mon, 30 Nov 2009 12:45:01 -0800 (PST) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20091130204501.775E53A699C@core3.amsl.com> Date: Mon, 30 Nov 2009 12:45:01 -0800 (PST) Cc: netconf@ietf.org Subject: [Netconf] I-D Action:draft-ietf-netconf-monitoring-10.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Nov 2009 20:45:01 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Network Configuration Working Group of the IETF. Title : YANG Module for NETCONF Monitoring Author(s) : M. Scott, M. Bjorklund Filename : draft-ietf-netconf-monitoring-10.txt Pages : 36 Date : 2009-11-30 This document defines a NETCONF data model to be used to monitor the NETCONF protocol. The monitoring data model includes information about NETCONF datastores, sessions, locks and statistics. This data facilitates the management of a NETCONF server. This document also defines methods for NETCONF clients to discover data models supported by a NETCONF server and defines a new NETCONF operation to retrieve them. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-netconf-monitoring-10.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-netconf-monitoring-10.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-11-30123717.I-D@ietf.org> --NextPart--