From bertietf@bwijnen.net Sat Aug 1 06:59: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 350D53A67B6 for ; Sat, 1 Aug 2009 06:59:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.907 X-Spam-Level: *** X-Spam-Status: No, score=3.907 tagged_above=-999 required=5 tests=[AWL=1.750, 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 IocgmC0TNJDL for ; Sat, 1 Aug 2009 06:59:40 -0700 (PDT) Received: from relay.versatel.net (beverwijk.tele2.vuurwerk.nl [62.250.3.53]) by core3.amsl.com (Postfix) with ESMTP id 6FCC33A6A71 for ; Sat, 1 Aug 2009 06:59:36 -0700 (PDT) Received: from [87.215.199.34] (helo=BertLaptop) by relay.versatel.net with smtp (Exim 4.69) (envelope-from ) id 1MXF7Z-0004uA-Ni for netconf@ietf.org; Sat, 01 Aug 2009 15:59:37 +0200 Message-ID: From: "Bert Wijnen \(IETF\)" To: "Netconf" Date: Sat, 1 Aug 2009 15:59:13 +0200 Organization: Consultant MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_1DDB_01CA12C1.040A1C40" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Windows Mail 6.0.6001.18000 X-MimeOLE: Produced By Microsoft MimeOLE V6.0.6001.18049 Subject: [Netconf] Access Control... are we ready to start work? 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, 01 Aug 2009 13:59:41 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_1DDB_01CA12C1.040A1C40 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable We are making good progress on our chartered work-items. At the same time, the NETMOD group seems to be on track to deliver YANG well before the next IETF meeting. We have stated many times that we need to have YANG done before we can properly start work on Access Control. It seems we will soon no longer = have that excuse. So the WG chairs sollicit individual Internet-Drafts that would might be = considered for WG work in this space. It would be good to have a few drafts (or at least one) ready byu the next IETF, so we can discuss it at the next meeting. Pls let us know who wants (and is going to) work on that. Bert and Mehmet ------=_NextPart_000_1DDB_01CA12C1.040A1C40 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
We are making good progress on our chartered=20 work-items.
 
At the same time, the NETMOD group seems to be on = track to=20 deliver YANG
well before the next IETF meeting.
 
We have stated many times that we need to have YANG = done=20 before we can
properly start work on Access Control. It seems we = will soon=20 no longer have
that excuse.
 
So the WG chairs sollicit individual Internet-Drafts = that=20 would might be
considered for WG work in this space. It would be = good to have=20 a few
drafts (or at least one) ready byu the next IETF, so = we can=20 discuss it
at the next meeting. Pls let us know who wants (and = is going=20 to) work
on that.
 
Bert and Mehmet
------=_NextPart_000_1DDB_01CA12C1.040A1C40-- From bertietf@bwijnen.net Sat Aug 1 06:59: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 350EA3A6CEF for ; Sat, 1 Aug 2009 06:59:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.532 X-Spam-Level: *** X-Spam-Status: No, score=3.532 tagged_above=-999 required=5 tests=[AWL=0.375, BAYES_60=1, 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 apZAGIcNmCB0 for ; Sat, 1 Aug 2009 06:59:40 -0700 (PDT) Received: from relay.versatel.net (beverwijk.tele2.vuurwerk.nl [62.250.3.53]) by core3.amsl.com (Postfix) with ESMTP id 012D63A6CB4 for ; Sat, 1 Aug 2009 06:59:37 -0700 (PDT) Received: from [87.215.199.34] (helo=BertLaptop) by relay.versatel.net with smtp (Exim 4.69) (envelope-from ) id 1MXF7Z-0004uA-Fz for netconf@ietf.org; Sat, 01 Aug 2009 15:59:37 +0200 Message-ID: From: "Bert Wijnen \(IETF\)" To: "Netconf" Date: Sat, 1 Aug 2009 15:55:38 +0200 Organization: Consultant MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_1DD5_01CA12C0.83D14030" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Windows Mail 6.0.6001.18000 X-MimeOLE: Produced By Microsoft MimeOLE V6.0.6001.18049 Subject: [Netconf] What do we do with RFC4742 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, 01 Aug 2009 13:59:41 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_1DD5_01CA12C0.83D14030 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Over the last few months, we have seen various comments on RFC4742. We can do one of two things: 1. start work on an RFC4742bis (if we want to do one, it would probably be good to have it ready at same time as 4741bis) 2. just keep a list of issues (preferably with clarifications) and do an 4742bis later. In either case, we like to see one or two volunteers to either edit the = document, or maintain the list of issues with clarifications Please let us know which option you prefer and if you want to volunteer. Bert and Mehmet ------=_NextPart_000_1DD5_01CA12C0.83D14030 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Over the last few months, we have seen various = comments on=20 RFC4742.
We can do one of two things:
 
1. start work on an RFC4742bis
   (if we want to do one, it would = probably be good=20 to have it ready at
    same time as = 4741bis)
2. just keep a list of issues (preferably with=20 clarifications) and do an
   4742bis later.
 
In either case, we like to see one or two volunteers = to either=20 edit the document,
or maintain the list of issues with=20 clarifications
 
Please let us know which option you prefer and if = you want to=20 volunteer.
 
Bert and Mehmet
------=_NextPart_000_1DD5_01CA12C0.83D14030-- From bertietf@bwijnen.net Sat Aug 1 06:59: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 6A7283A67B6 for ; Sat, 1 Aug 2009 06:59:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.908 X-Spam-Level: ** X-Spam-Status: No, score=2.908 tagged_above=-999 required=5 tests=[AWL=0.750, 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 x6U7OZbqekA7 for ; Sat, 1 Aug 2009 06:59:40 -0700 (PDT) Received: from relay.versatel.net (beverwijk.tele2.vuurwerk.nl [62.250.3.53]) by core3.amsl.com (Postfix) with ESMTP id 68AEA3A6D04 for ; Sat, 1 Aug 2009 06:59:37 -0700 (PDT) Received: from [87.215.199.34] (helo=BertLaptop) by relay.versatel.net with smtp (Exim 4.69) (envelope-from ) id 1MXF7Z-0004uA-81 for netconf@ietf.org; Sat, 01 Aug 2009 15:59:37 +0200 Message-ID: <3BEFE3886E72400593C93D48CF303724@BertLaptop> From: "Bert Wijnen \(IETF\)" To: References: <20090722.235941.67264633.mbj@tail-f.com> <200907230433.n6N4XJ6G064490@idle.juniper.net> <20090723.215005.222579354.mbj@tail-f.com><4A6B2BEA.9010002@netconfcentral.com> <4A6C5373.9040501@bwijnen.net> In-Reply-To: <4A6C5373.9040501@bwijnen.net> Date: Sat, 1 Aug 2009 15:51:54 +0200 Organization: Consultant MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_1DC6_01CA12BF.FE0367D0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Windows Mail 6.0.6001.18000 X-MimeOLE: Produced By Microsoft MimeOLE V6.0.6001.18049 Subject: [Netconf] Database Architecture OK or NOT-OK? 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, 01 Aug 2009 13:59:41 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_1DC6_01CA12BF.FE0367D0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable We (as WG chairs) have not seen much reaction to the email from Andy in = which he stated I wish we had time to work on the NETCONF database architecture, because it isn't very good. I did respond... but noone else. As WG chairs, we ask ALL WG participants to SPEAK UP NOW if they think = we should spend some time on this topic. If not, then we will drop it from = our list of things to do (at least for the forseeable future). Bert and Mehmet ----- Original Message -----=20 From: Bert (IETF) Wijnen=20 To: Andy Bierman=20 Cc: netconf@ietf.org=20 Sent: Sunday, July 26, 2009 3:00 PM Subject: Re: [Netconf] Comments :draft-ietf-netconf-4741bis-01.txt Andy wrote: > I wish we had time to work on the NETCONF database architecture, > because it isn't very good. > =20 > Andy > =20 I wonder if others (many) feel the same? Because if we do believe that the db architecture is not good enough,=20 then we better think about a possible better architecture now....=20 before we start adding all sorts of new/other things. speaking as a contributer Bert ------=_NextPart_000_1DC6_01CA12BF.FE0367D0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
We (as WG chairs) have not seen much reaction = to the=20 email from Andy in which
he stated
       I wish we had = time to=20 work on the NETCONF database = architecture,
     =20  because it isn't very good.
I did respond... but noone=20 else.
 
As WG chairs, we ask ALL WG participants to SPEAK UP = NOW if=20 they think we
should spend some time on this topic. If not, then = we will=20 drop it from our list
of things to do (at least for the forseeable=20 future).
 
 
Bert and Mehmet
 
----- Original Message -----
From:=20 Bert (IETF)=20 Wijnen
Sent: Sunday, July 26, 2009 = 3:00 PM
Subject: Re: [Netconf] Comments = :draft-ietf-netconf-4741bis-01.txt

Andy wrote:
> I wish we had time to work on the NETCONF = database=20 architecture,
> because it isn't very good.
>   =
>=20 Andy
>  

I wonder if others (many) feel the=20 same?
Because if we do believe that the db architecture is not good = enough,=20
then we better think about a possible better architecture now.... =
before we start adding all sorts of new/other=20 things.

speaking as a=20 contributer
Bert
------=_NextPart_000_1DC6_01CA12BF.FE0367D0-- From andy@netconfcentral.com Sat Aug 1 08:20:29 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 A503C3A67F4 for ; Sat, 1 Aug 2009 08:20:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.489 X-Spam-Level: X-Spam-Status: No, score=-2.489 tagged_above=-999 required=5 tests=[AWL=0.110, 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 30basSp9+CCP for ; Sat, 1 Aug 2009 08:20:29 -0700 (PDT) Received: from n5a.bullet.mud.yahoo.com (n5a.bullet.mud.yahoo.com [209.191.126.232]) by core3.amsl.com (Postfix) with SMTP id D27EE3A68E1 for ; Sat, 1 Aug 2009 08:20:28 -0700 (PDT) Received: from [209.191.108.96] by n5.bullet.mud.yahoo.com with NNFMP; 01 Aug 2009 15:20:29 -0000 Received: from [68.142.201.69] by t3.bullet.mud.yahoo.com with NNFMP; 01 Aug 2009 15:20:29 -0000 Received: from [127.0.0.1] by omp421.mail.mud.yahoo.com with NNFMP; 01 Aug 2009 15:20:29 -0000 X-Yahoo-Newman-Id: 171459.69277.bm@omp421.mail.mud.yahoo.com Received: (qmail 69629 invoked from network); 1 Aug 2009 15:20:28 -0000 Received: from unknown (HELO ?192.168.0.10?) (andy@68.120.85.49 with plain) by smtp105.sbc.mail.sp1.yahoo.com with SMTP; 1 Aug 2009 15:20:28 -0000 X-YMail-OSG: 7xTv9IEVM1neX.azaUlI07XbUENu4FZDvGtekSw9tZKPrwtG6YKMTWvX1Ls3iZvH6lsRKUvAPvNI7npkbYm9hk1e_LNbPAVWtJy9Z0mabpXClphBF6oI1CV0GrxxpUFedcU5JSWUlDFtPsI0lOfaoDNAbS640ffNjqnhQxk6rxCOI1HcoarIWrlvLdo_D9A.f18.uYraGuYnH2Co.za5EqO2i2kYMj0mt6vJAT6fq37oEMnT6ATDP3AL.beyUktGEzn7WTUSR3t1Zg-- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4A745D4F.9070504@netconfcentral.com> Date: Sat, 01 Aug 2009 08:20:47 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.22 (X11/20090608) MIME-Version: 1.0 To: NETCONF Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [Netconf] :writable-running and :candidate 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, 01 Aug 2009 15:20:29 -0000 Hi, I asked (in email) how the :candidate and :writable-running capabilities can possibly be supported on the same agent. I never got an answer. I do not understand how the candidate database stays in synch with the running database if user B can write to running while user A has the candidate locked. Also what happens to the edits made by user A when user B issues a ? Are the changes just made to running undone (they were not in the candidate, so they must be undone, right?) Is this part of the intended database architecture or not? And if user A does a copy-config from a locked candidate to running? That is allowed of course. Andy From lhotka@cesnet.cz Sat Aug 1 08:23: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 3CA7B3A69ED for ; Sat, 1 Aug 2009 08:23:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.16 X-Spam-Level: X-Spam-Status: No, score=-1.16 tagged_above=-999 required=5 tests=[AWL=0.090, 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 6dc6asDpA2yV for ; Sat, 1 Aug 2009 08:23:04 -0700 (PDT) Received: from office2.cesnet.cz (office2.cesnet.cz [195.113.144.244]) by core3.amsl.com (Postfix) with ESMTP id 3672B3A672F for ; Sat, 1 Aug 2009 08:23:04 -0700 (PDT) Received: from [172.29.2.201] (asus-gx.lhotka.cesnet.cz [195.113.161.161]) by office2.cesnet.cz (Postfix) with ESMTP id BFF1BD800BD for ; Sat, 1 Aug 2009 17:23:05 +0200 (CEST) From: Ladislav Lhotka To: netconf@ietf.org In-Reply-To: <3BEFE3886E72400593C93D48CF303724@BertLaptop> References: <20090722.235941.67264633.mbj@tail-f.com> <200907230433.n6N4XJ6G064490@idle.juniper.net> <20090723.215005.222579354.mbj@tail-f.com> <4A6B2BEA.9010002@netconfcentral.com> <4A6C5373.9040501@bwijnen.net> <3BEFE3886E72400593C93D48CF303724@BertLaptop> Content-Type: text/plain; charset="UTF-8" Organization: CESNET Date: Sat, 01 Aug 2009 17:23:04 +0200 Message-Id: <1249140184.14644.25.camel@missotis> Mime-Version: 1.0 X-Mailer: Evolution 2.26.1 Content-Transfer-Encoding: 8bit Subject: Re: [Netconf] Database Architecture OK or NOT-OK? 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, 01 Aug 2009 15:23:05 -0000 Hi Bert, I do think some time should be spent on this. To start with, it would be useful to agree on a definition of the term "configuration datastore". The definition in 4741bis (sec. 5.1) "A configuration datastore is defined as the complete set of configuration data that is required to get a device from its initial default state into a desired operational state." is hardly satisfactory because it depends on the notion of 'initial default state' which is not defined and allows multiple interpretations. I understand implementations use slightly different approaches but IMO we can hardly talk about database architecture if the base information set is not properly defined. Lada Bert Wijnen (IETF) píše v So 01. 08. 2009 v 15:51 +0200: > We (as WG chairs) have not seen much reaction to the email from Andy > in which > he stated > I wish we had time to work on the NETCONF database > architecture, > because it isn't very good. > I did respond... but noone else. > > As WG chairs, we ask ALL WG participants to SPEAK UP NOW if they think > we > should spend some time on this topic. If not, then we will drop it > from our list > of things to do (at least for the forseeable future). > > > Bert and Mehmet > > ----- Original Message ----- > From: Bert (IETF) Wijnen > To: Andy Bierman > Cc: netconf@ietf.org > Sent: Sunday, July 26, 2009 3:00 PM > Subject: Re: [Netconf] > Comments :draft-ietf-netconf-4741bis-01.txt > > > Andy wrote: > > I wish we had time to work on the NETCONF database > architecture, > > because it isn't very good. > > > > Andy > > > > I wonder if others (many) feel the same? > Because if we do believe that the db architecture is not good > enough, > then we better think about a possible better architecture > now.... > before we start adding all sorts of new/other things. > > speaking as a contributer > Bert > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf -- Ladislav Lhotka, CESNET PGP Key ID: E74E8C0C From andy@netconfcentral.com Sat Aug 1 09:11: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 0EA3B3A6A9F for ; Sat, 1 Aug 2009 09:11:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.492 X-Spam-Level: X-Spam-Status: No, score=-2.492 tagged_above=-999 required=5 tests=[AWL=0.107, 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 dPRcRcZfP9r9 for ; Sat, 1 Aug 2009 09:11:02 -0700 (PDT) Received: from smtp114.sbc.mail.mud.yahoo.com (smtp114.sbc.mail.mud.yahoo.com [68.142.198.213]) by core3.amsl.com (Postfix) with SMTP id 2EC303A6403 for ; Sat, 1 Aug 2009 09:11:01 -0700 (PDT) Received: (qmail 81827 invoked from network); 1 Aug 2009 16:11:02 -0000 Received: from unknown (HELO ?192.168.0.10?) (andy@68.120.85.49 with plain) by smtp114.sbc.mail.mud.yahoo.com with SMTP; 1 Aug 2009 16:11:02 -0000 X-YMail-OSG: BQ4lzj0VM1lOZyMnwuiw7xTxwvG99EGB5iFLxKHb_uEdawHo8RYa73N3ujtINrr4dgVZ3wY7dltDtl7skN7vwIXG.reOXaIddKPtKaKcfk98KOulUBTU4XN.WjOIdz1ZIeT9wyI2sEVTM7p3JJI_lBqzoj9YkUX0ZLzrGo_hQYElui6hhTjsl5_6CoQumTB9ZFpxrSMHxGhyVY.Av6zoMBPL4Y22arNPW9BKwJogR6RbvsBU95MitWagNjMQE__0TpQRPAPe1_79eBX6.UBKuRdsKo7oErdG55Xb1dPj0EotJQ-- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4A746929.4090508@netconfcentral.com> Date: Sat, 01 Aug 2009 09:11:21 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.22 (X11/20090608) MIME-Version: 1.0 To: "Bert Wijnen (IETF)" References: <20090722.235941.67264633.mbj@tail-f.com> <200907230433.n6N4XJ6G064490@idle.juniper.net> <20090723.215005.222579354.mbj@tail-f.com><4A6B2BEA.9010002@netconfcentral.com> <4A6C5373.9040501@bwijnen.net> <3BEFE3886E72400593C93D48CF303724@BertLaptop> In-Reply-To: <3BEFE3886E72400593C93D48CF303724@BertLaptop> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: netconf@ietf.org Subject: Re: [Netconf] Database Architecture OK or NOT-OK? 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, 01 Aug 2009 16:11:03 -0000 Bert Wijnen (IETF) wrote: > We (as WG chairs) have not seen much reaction to the email from Andy in > which > he stated > I wish we had time to work on the NETCONF database architecture, > because it isn't very good. > I did respond... but noone else. > I regret using the over-loaded term 'architecture'. I don't mind just focusing on details. That's what this WG knows how to do best. I suppose 'ad-hoc' counts as an design approach. It's been working so well for CLI all these years. Andy > As WG chairs, we ask ALL WG participants to SPEAK UP NOW if they think we > should spend some time on this topic. If not, then we will drop it from > our list > of things to do (at least for the forseeable future). > > > Bert and Mehmet > > ----- Original Message ----- > > *From:* Bert (IETF) Wijnen > *To:* Andy Bierman > *Cc:* netconf@ietf.org > *Sent:* Sunday, July 26, 2009 3:00 PM > *Subject:* Re: [Netconf] Comments :draft-ietf-netconf-4741bis-01.txt > > Andy wrote: > > I wish we had time to work on the NETCONF database architecture, > > because it isn't very good. > > > > Andy > > > > I wonder if others (many) feel the same? > Because if we do believe that the db architecture is not good enough, > then we better think about a possible better architecture now.... > before we start adding all sorts of new/other things. > > speaking as a contributer > Bert > > > ------------------------------------------------------------------------ > > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf From andy@netconfcentral.com Sat Aug 1 09:59:04 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 CB1373A696F for ; Sat, 1 Aug 2009 09:59:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.497 X-Spam-Level: X-Spam-Status: No, score=-2.497 tagged_above=-999 required=5 tests=[AWL=0.102, 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 grRx9RcAlv4Q for ; Sat, 1 Aug 2009 09:59:04 -0700 (PDT) Received: from smtp111.sbc.mail.mud.yahoo.com (smtp111.sbc.mail.mud.yahoo.com [68.142.198.210]) by core3.amsl.com (Postfix) with SMTP id F35073A6955 for ; Sat, 1 Aug 2009 09:59:03 -0700 (PDT) Received: (qmail 10999 invoked from network); 1 Aug 2009 16:59:04 -0000 Received: from unknown (HELO ?192.168.0.10?) (andy@68.120.85.49 with plain) by smtp111.sbc.mail.mud.yahoo.com with SMTP; 1 Aug 2009 16:59:04 -0000 X-YMail-OSG: UlEECwsVM1ncoOqFgZ.z1_9VEQNVFva9BBH1nJpiazdMxtl_ZIMmaF38rpK6qTQ9GkzXhfoL1.oV4Gm7n63CKVgf1zuhktv7zLhmazuNLx2CjQg0zkc4uQqu48rddPZHffLhy1oyC90.Qx0BpsR6QCHISiT3ZBwwQM4.d8GfWfV8JwwZvHQgkpyIbTOxsIqvenA3P6yQAUBepporaJyRehnVzRth1I_EdouUakwrGcOWw2TCDRKPLEG2ldOVOasJImEqWyUzfZ4VBTtGwnE1c6USzjSMN_FKLhj3PzPfy7t1wToxGw-- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4A7473F3.5080709@netconfcentral.com> Date: Sat, 01 Aug 2009 09:57:23 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.22 (X11/20090608) MIME-Version: 1.0 To: NETCONF Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [Netconf] partial locking for candidate and startup? 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, 01 Aug 2009 16:59:04 -0000 Hi, Are there any plans to extend the partial locking feature to the candidate and startup databases? The WG has only addressed the 'SQL database model' (write directly to the persistent database). However, there are many networking devices which use the :candidate or :startup capabilities. If so, the partial locking feature is not applicable. It is possible that partial locking for candidate and startup would require too many changes to the protocol. I am just wondering if this decision has already been made or not. Andy From j.schoenwaelder@jacobs-university.de Sat Aug 1 10:00: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 E66903A6990 for ; Sat, 1 Aug 2009 10:00:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.205 X-Spam-Level: X-Spam-Status: No, score=-2.205 tagged_above=-999 required=5 tests=[AWL=0.044, 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 wx3RwQMOJd6J for ; Sat, 1 Aug 2009 10:00:48 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id F417F3A6971 for ; Sat, 1 Aug 2009 10:00:47 -0700 (PDT) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id BDA4FC0012; Sat, 1 Aug 2009 19:00:49 +0200 (CEST) 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 zQaGWClewiby; Sat, 1 Aug 2009 19:00:49 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 04A77C000A; Sat, 1 Aug 2009 19:00:48 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 6C3E0B73EF7; Sat, 1 Aug 2009 19:00:49 +0200 (CEST) Date: Sat, 1 Aug 2009 19:00:49 +0200 From: Juergen Schoenwaelder To: "Bert Wijnen (IETF)" Message-ID: <20090801170049.GA17957@elstar.local> Mail-Followup-To: "Bert Wijnen (IETF)" , "netconf@ietf.org" References: <20090722.235941.67264633.mbj@tail-f.com> <200907230433.n6N4XJ6G064490@idle.juniper.net> <20090723.215005.222579354.mbj@tail-f.com> <4A6B2BEA.9010002@netconfcentral.com> <4A6C5373.9040501@bwijnen.net> <3BEFE3886E72400593C93D48CF303724@BertLaptop> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3BEFE3886E72400593C93D48CF303724@BertLaptop> User-Agent: Mutt/1.5.19 (2009-01-05) Cc: "netconf@ietf.org" Subject: Re: [Netconf] Database Architecture OK or NOT-OK? 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: Sat, 01 Aug 2009 17:00:49 -0000 On Sat, Aug 01, 2009 at 03:51:54PM +0200, Bert Wijnen (IETF) wrote: > We (as WG chairs) have not seen much reaction to the email from Andy in which > he stated > I wish we had time to work on the NETCONF database architecture, > because it isn't very good. > I did respond... but noone else. > > As WG chairs, we ask ALL WG participants to SPEAK UP NOW if they > think we should spend some time on this topic. If not, then we will > drop it from our list of things to do (at least for the forseeable > future). A statement like "it isn't very good" is a bit too vague to react on and this is why there is likely so little reaction. /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 Aug 1 10:46: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 3DFE93A6A43 for ; Sat, 1 Aug 2009 10:46:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.5 X-Spam-Level: X-Spam-Status: No, score=-2.5 tagged_above=-999 required=5 tests=[AWL=0.099, 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 ylgcj8UVcblR for ; Sat, 1 Aug 2009 10:46:15 -0700 (PDT) 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 6B5CC3A6A12 for ; Sat, 1 Aug 2009 10:46:15 -0700 (PDT) Received: from [68.142.200.226] by n15.bullet.mail.mud.yahoo.com with NNFMP; 01 Aug 2009 17:46:16 -0000 Received: from [68.142.201.70] by t7.bullet.mud.yahoo.com with NNFMP; 01 Aug 2009 17:46:16 -0000 Received: from [127.0.0.1] by omp422.mail.mud.yahoo.com with NNFMP; 01 Aug 2009 17:46:16 -0000 X-Yahoo-Newman-Id: 72449.98367.bm@omp422.mail.mud.yahoo.com Received: (qmail 12407 invoked from network); 1 Aug 2009 17:46:15 -0000 Received: from unknown (HELO ?192.168.0.10?) (andy@68.120.85.49 with plain) by smtp103.sbc.mail.sp1.yahoo.com with SMTP; 1 Aug 2009 17:46:15 -0000 X-YMail-OSG: za4RTFYVM1myWm2Bd8haSgMlQrQa9iIsi9KFqZ.u5SmJ5Zn_O.Z7ljrEuCUD7boyJoddEDVuN5lUw0_7cqZLoIS4LMF22y8itGhDViXM5o5Qnbv7T.eENGy3a.Fs_QcAR_FqvqUvGWbmmjxs48E1ITTyKvgH5_ZsKxZnbQW9Yc.HTYXkZX506B92MsannsfbtQopRkJVXwSHWhynm4mJ7ODA5pKFoAvSBOmi5rtUR00xOAi8dvC_UJWxrGgQUdhTqrzCRSMzSYaRq1QMMWaGRuoZY4jgiRLancmzXirvAcryh09Eig-- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4A747F02.8060408@netconfcentral.com> Date: Sat, 01 Aug 2009 10:44:34 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.22 (X11/20090608) MIME-Version: 1.0 To: "Bert Wijnen (IETF)" , "netconf@ietf.org" References: <20090722.235941.67264633.mbj@tail-f.com> <200907230433.n6N4XJ6G064490@idle.juniper.net> <20090723.215005.222579354.mbj@tail-f.com> <4A6B2BEA.9010002@netconfcentral.com> <4A6C5373.9040501@bwijnen.net> <3BEFE3886E72400593C93D48CF303724@BertLaptop> <20090801170049.GA17957@elstar.local> In-Reply-To: <20090801170049.GA17957@elstar.local> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [Netconf] Database Architecture OK or NOT-OK? 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, 01 Aug 2009 17:46:16 -0000 Juergen Schoenwaelder wrote: > On Sat, Aug 01, 2009 at 03:51:54PM +0200, Bert Wijnen (IETF) wrote: > >> We (as WG chairs) have not seen much reaction to the email from Andy in which >> he stated >> I wish we had time to work on the NETCONF database architecture, >> because it isn't very good. >> I did respond... but noone else. >> >> As WG chairs, we ask ALL WG participants to SPEAK UP NOW if they >> think we should spend some time on this topic. If not, then we will >> drop it from our list of things to do (at least for the forseeable >> future). > > A statement like "it isn't very good" is a bit too vague to react on > and this is why there is likely so little reaction. > Yes -- in my defense it was taken out of a long email filled with issues, some of which are still unresolved. IMO, the FTP-mode of NETCONF is a throwback to the CLI world, that does not fit at all with the edit-config/commit/discard-changes model. It is really just CLI with angle brackets. Why would an operator bother using this 'brute force' manual mode of NETCONF, instead of the native CLI? > /js > Andy From j.schoenwaelder@jacobs-university.de Sat Aug 1 10:59: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 D8E543A6940 for ; Sat, 1 Aug 2009 10:59:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.206 X-Spam-Level: X-Spam-Status: No, score=-2.206 tagged_above=-999 required=5 tests=[AWL=0.043, 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 BXPH0TmCnSXG for ; Sat, 1 Aug 2009 10:59:51 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id EF6BC3A6895 for ; Sat, 1 Aug 2009 10:59:50 -0700 (PDT) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id E1E0FC0012; Sat, 1 Aug 2009 19:59:52 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius4.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id nOgxdriA8Nzk; Sat, 1 Aug 2009 19:59:52 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id B03FDC0008; Sat, 1 Aug 2009 19:59:51 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 2B5F9B73FDB; Sat, 1 Aug 2009 19:59:52 +0200 (CEST) Date: Sat, 1 Aug 2009 19:59:52 +0200 From: Juergen Schoenwaelder To: Andy Bierman Message-ID: <20090801175952.GA17993@elstar.local> Mail-Followup-To: Andy Bierman , "Bert Wijnen (IETF)" , "netconf@ietf.org" References: <20090722.235941.67264633.mbj@tail-f.com> <200907230433.n6N4XJ6G064490@idle.juniper.net> <20090723.215005.222579354.mbj@tail-f.com> <4A6B2BEA.9010002@netconfcentral.com> <4A6C5373.9040501@bwijnen.net> <3BEFE3886E72400593C93D48CF303724@BertLaptop> <20090801170049.GA17957@elstar.local> <4A747F02.8060408@netconfcentral.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4A747F02.8060408@netconfcentral.com> User-Agent: Mutt/1.5.19 (2009-01-05) Cc: "netconf@ietf.org" Subject: Re: [Netconf] Database Architecture OK or NOT-OK? 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: Sat, 01 Aug 2009 17:59:52 -0000 On Sat, Aug 01, 2009 at 07:44:34PM +0200, Andy Bierman wrote: > IMO, the FTP-mode of NETCONF is a throwback to the > CLI world, that does not fit at all with the > edit-config/commit/discard-changes model. > It is really just CLI with angle brackets. > Why would an operator bother using this 'brute force' manual > mode of NETCONF, instead of the native CLI? FTP-mode? I am puzzled. I am even further away from understanding the issue. /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 Aug 1 11:42: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 5D93D3A6A86 for ; Sat, 1 Aug 2009 11:42:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.502 X-Spam-Level: X-Spam-Status: No, score=-2.502 tagged_above=-999 required=5 tests=[AWL=0.097, 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 rI7Wg5ZcnsPh for ; Sat, 1 Aug 2009 11:42:48 -0700 (PDT) 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 640323A6955 for ; Sat, 1 Aug 2009 11:42:45 -0700 (PDT) Received: from [68.142.200.226] by n15.bullet.mail.mud.yahoo.com with NNFMP; 01 Aug 2009 18:42:44 -0000 Received: from [68.142.201.73] by t7.bullet.mud.yahoo.com with NNFMP; 01 Aug 2009 18:42:44 -0000 Received: from [127.0.0.1] by omp425.mail.mud.yahoo.com with NNFMP; 01 Aug 2009 18:42:44 -0000 X-Yahoo-Newman-Id: 207339.24451.bm@omp425.mail.mud.yahoo.com Received: (qmail 15145 invoked from network); 1 Aug 2009 18:42:43 -0000 Received: from unknown (HELO ?192.168.0.10?) (andy@68.120.85.49 with plain) by smtp104.sbc.mail.sp1.yahoo.com with SMTP; 1 Aug 2009 18:42:43 -0000 X-YMail-OSG: K0oBAXsVM1nzJZsVPLu9N2QgSZWxoyhKx7iy6BFM6byjO3CwZcHwXQG6grz5XPWnsTotru1lU9hThUYKQ2Twg8CZeTbOcYL2Z8dapkCgPH3Fpuu4ONGWwUiB7Nk2RUnCueJRl.rhQh.QhMfalWpjo9NuB.Yn0BCeQp0Xhh5Fd8NftHhVs6jgRjvVhtEci2ECTL3DuaSlDkgjfOgKor.dr.nNM8wuQDeOuYE5JZDyUYYNSVVbnhRljgB3.A2BYDS3JInXiO3gZ2OuDQ-- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4A748CB7.1030208@netconfcentral.com> Date: Sat, 01 Aug 2009 11:43:03 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.22 (X11/20090608) MIME-Version: 1.0 To: Andy Bierman , "Bert Wijnen (IETF)" , "netconf@ietf.org" References: <20090722.235941.67264633.mbj@tail-f.com> <200907230433.n6N4XJ6G064490@idle.juniper.net> <20090723.215005.222579354.mbj@tail-f.com> <4A6B2BEA.9010002@netconfcentral.com> <4A6C5373.9040501@bwijnen.net> <3BEFE3886E72400593C93D48CF303724@BertLaptop> <20090801170049.GA17957@elstar.local> <4A747F02.8060408@netconfcentral.com> <20090801175952.GA17993@elstar.local> In-Reply-To: <20090801175952.GA17993@elstar.local> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [Netconf] Database Architecture OK or NOT-OK? 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, 01 Aug 2009 18:42:52 -0000 Juergen Schoenwaelder wrote: > On Sat, Aug 01, 2009 at 07:44:34PM +0200, Andy Bierman wrote: > >> IMO, the FTP-mode of NETCONF is a throwback to the >> CLI world, that does not fit at all with the >> edit-config/commit/discard-changes model. >> It is really just CLI with angle brackets. >> Why would an operator bother using this 'brute force' manual >> mode of NETCONF, instead of the native CLI? > > FTP-mode? I am puzzled. I am even further away from understanding the > issue. > copy-config into running and candidate are just file copy operations. The agent is supposed to figure out what changed and only alter those device features. Worst case, the agent is allowed to blow away the entire config and re-initialize every feature with its cut-and-pasted config replacement (XML subtree). The manager has no idea what will really happen from agent to agent. IMO this is not nearly as clean as the edit-config operation, which, if used correctly, can clearly state the intent and scope of the desired config changes. It is just my opinion, so I don't think there are any WG issues to resolve. > /js > Andy From dbharrington@comcast.net Sun Aug 2 02:47:42 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 23B533A69E5 for ; Sun, 2 Aug 2009 02:47:42 -0700 (PDT) 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=[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 I01qSy4kjDCc for ; Sun, 2 Aug 2009 02:47:40 -0700 (PDT) Received: from QMTA09.emeryville.ca.mail.comcast.net (qmta09.emeryville.ca.mail.comcast.net [76.96.30.96]) by core3.amsl.com (Postfix) with ESMTP id AC07F3A69A0 for ; Sun, 2 Aug 2009 02:47:40 -0700 (PDT) Received: from OMTA21.emeryville.ca.mail.comcast.net ([76.96.30.88]) by QMTA09.emeryville.ca.mail.comcast.net with comcast id PMnj1c0021u4NiLA9Mnjr4; Sun, 02 Aug 2009 09:47:43 +0000 Received: from Harrington73653 ([78.64.88.120]) by OMTA21.emeryville.ca.mail.comcast.net with comcast id PMnW1c0012bnT5q8hMnZNk; Sun, 02 Aug 2009 09:47:41 +0000 From: "David B Harrington" To: "'Bert Wijnen \(IETF\)'" , References: <20090722.235941.67264633.mbj@tail-f.com> <200907230433.n6N4XJ6G064490@idle.juniper.net> <20090723.215005.222579354.mbj@tail-f.com><4A6B2BEA.9010002@netconfcentral.com><4A6C5373.9040501@bwijnen.net> <3BEFE3886E72400593C93D48CF303724@BertLaptop> Date: Sun, 2 Aug 2009 11:47:27 +0200 Message-ID: <005a01ca1356$45619a20$7858404e@china.huawei.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_005B_01CA1367.08EA6A20" X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <3BEFE3886E72400593C93D48CF303724@BertLaptop> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 thread-index: AcoSsGWBFSDWUGoWThC2n0wGNiWkHgApZq6Q Subject: Re: [Netconf] Database Architecture OK or NOT-OK? 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, 02 Aug 2009 09:47:42 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_005B_01CA1367.08EA6A20 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi, You have taken a comment out of context, and have not identified the original email where Andy made this remark. Can you identify the original message so readers can see what Andy had to say? dbh _____ From: netconf-bounces@ietf.org [mailto:netconf-bounces@ietf.org] On Behalf Of Bert Wijnen (IETF) Sent: Saturday, August 01, 2009 3:52 PM To: netconf@ietf.org Subject: [Netconf] Database Architecture OK or NOT-OK? We (as WG chairs) have not seen much reaction to the email from Andy in which he stated I wish we had time to work on the NETCONF database architecture, because it isn't very good. I did respond... but noone else. As WG chairs, we ask ALL WG participants to SPEAK UP NOW if they think we should spend some time on this topic. If not, then we will drop it from our list of things to do (at least for the forseeable future). Bert and Mehmet ----- Original Message ----- From: Bert (IETF) Wijnen To: Andy Bierman Cc: netconf@ietf.org Sent: Sunday, July 26, 2009 3:00 PM Subject: Re: [Netconf] Comments :draft-ietf-netconf-4741bis-01.txt Andy wrote: > I wish we had time to work on the NETCONF database architecture, > because it isn't very good. > > Andy > I wonder if others (many) feel the same? Because if we do believe that the db architecture is not good enough, then we better think about a possible better architecture now.... before we start adding all sorts of new/other things. speaking as a contributer Bert ------=_NextPart_000_005B_01CA1367.08EA6A20 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi,
 
You have taken a comment out of context, and = have not=20 identified the original email where Andy made this = remark.
Can you identify the original message so = readers can see=20 what Andy had to say?
 
dbh

From: netconf-bounces@ietf.org=20 [mailto:netconf-bounces@ietf.org] On Behalf Of Bert Wijnen=20 (IETF)
Sent: Saturday, August 01, 2009 3:52 PM
To: = netconf@ietf.org
Subject: [Netconf] Database Architecture OK = or=20 NOT-OK?

We (as WG chairs) have not seen much reaction = to the=20 email from Andy in which
he stated
       I wish we had = time to=20 work on the NETCONF database = architecture,
     =20  because it isn't very good.
I did respond... but noone=20 else.
 
As WG chairs, we ask ALL WG participants to SPEAK = UP NOW if=20 they think we
should spend some time on this topic. If not, then = we will=20 drop it from our list
of things to do (at least for the forseeable=20 future).
 
 
Bert and Mehmet
 
----- Original Message -----
From:=20 Bert (IETF)=20 Wijnen
Sent: Sunday, July 26, 2009 = 3:00=20 PM
Subject: Re: [Netconf] = Comments=20 :draft-ietf-netconf-4741bis-01.txt

Andy wrote:
> I wish we had time to work on the NETCONF = database=20 architecture,
> because it isn't very = good.
>  =20
> Andy
>  

I wonder if others (many) = feel the=20 same?
Because if we do believe that the db architecture is not = good=20 enough,
then we better think about a possible better = architecture=20 now....
before we start adding all sorts of new/other=20 things.

speaking as a=20 contributer
Bert
------=_NextPart_000_005B_01CA1367.08EA6A20-- From bertietf@bwijnen.net Sun Aug 2 13:58:42 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 A4A9C3A6BE0 for ; Sun, 2 Aug 2009 13:58:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.627 X-Spam-Level: ** X-Spam-Status: No, score=2.627 tagged_above=-999 required=5 tests=[AWL=0.655, BAYES_40=-0.185, 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 C4ef0soXkIor for ; Sun, 2 Aug 2009 13:58:41 -0700 (PDT) Received: from relay.versatel.net (beverwijk.tele2.vuurwerk.nl [62.250.3.53]) by core3.amsl.com (Postfix) with ESMTP id 71D133A6C04 for ; Sun, 2 Aug 2009 13:58:41 -0700 (PDT) Received: from [87.215.199.34] (helo=BertLaptop) by relay.versatel.net with smtp (Exim 4.69) (envelope-from ) id 1MXi8g-00055P-B3; Sun, 02 Aug 2009 22:58:42 +0200 Message-ID: From: "Bert Wijnen \(IETF\)" To: "David B Harrington" Date: Sun, 2 Aug 2009 22:58:09 +0200 Organization: Consultant MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_20F5_01CA13C4.B4769AF0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Windows Mail 6.0.6001.18000 X-MimeOLE: Produced By Microsoft MimeOLE V6.0.6001.18049 Cc: Netconf Subject: [Netconf] Fw: Database Architecture OK or NOT-OK? 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, 02 Aug 2009 20:58:42 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_20F5_01CA13C4.B4769AF0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable > Hi, > > You have taken a comment out of context, and have not identified the=20 > original email where Andy made this remark. > Can you identify the original message so readers can see what Andy had = to=20 > say? > > dbh See the bottom of the following post from Andy: ----- Original Message -----=20 From: Andy Bierman To: Martin Bjorklund Cc: netconf@ietf.org Sent: Saturday, July 25, 2009 5:59 PM Subject: Re: [Netconf] Comments :draft-ietf-netconf-4741bis-01.txt Martin Bjorklund wrote: > Phil Shafer wrote: >> Martin Bjorklund writes: >>> RFC 4741 says: >>> Delete a configuration datastore. >> This makes little sense. What does it mean to delete ? > > According to 4741, running cannot be deleted. > good! I find the and operations to be the absolute worst part of NETCONF. It is obvious from studying the protocol that there was no clear or shared understanding of the database architecture. Now with partial-locking, it is even worse. * every agent MUST have a database * every agent MUST have exactly 1 database that can be the target of an operation. (Writing to both and does not work!) * therefore the agent MUST support the :candidate OR :writable-running capabilities, but not both) * the :candidate and :startup capabilities are independent, not mutually exclusive. (Is there any agreement on these points?) I changed my mind on 'minimal operations'. I think and on the "NV version" are too useful for operators to leave as optional. So the table in 4741bis, 8.7.5.1 is OK I do not like all the combinations for that occur when :candidate and :startup are both supported. Or for that matter, just :candidate. 8.3.5.1. , , , and The candidate configuration can be used as a source or target of any , , , or operation as a or parameter. The element is used to indicate the candidate configuration: This first sentence is clearly wrong. You cannot copy from candidate to running. You can only use for that. (Not sure about copy from candidate to startup.) You should not be able to copy from running to candidate either. We have for that. I wish we had time to work on the NETCONF database architecture, because it isn't very good. > > /martin > Andy ------=_NextPart_000_20F5_01CA13C4.B4769AF0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable > Hi,
>
> You have taken a = comment out of=20 context, and have not identified the
> original email where Andy = made=20 this remark.
> Can you identify the original message so readers = can see=20 what Andy had to
> say?
>
> dbh

See the bottom = of the=20 following post from Andy:

----- Original Message -----
From: = Andy=20 Bierman
To: Martin Bjorklund
Cc: netconf@ietf.org
Sent: Saturday, = July 25,=20 2009 5:59 PM
Subject: Re: [Netconf] Comments=20 :draft-ietf-netconf-4741bis-01.txt


Martin Bjorklund = wrote:
>=20 Phil Shafer <phil@juniper.net>=20 wrote:
>> Martin Bjorklund writes:
>>> RFC 4741=20 says:
>>>  Delete a configuration = datastore.
>> This=20 makes little sense.  What does it mean to delete=20 <running>?
>
> According to 4741, running cannot be=20 deleted.
>

good!

I find the <copy-config> and=20 <delete-config> operations
to be the absolute worst part of=20 NETCONF.

It is obvious from studying the protocol that there was=20 no
clear or shared understanding of the database architecture.
Now = with=20 partial-locking, it is even worse.

   * every agent = MUST have a=20 <running> database
   * every agent MUST have exactly = 1=20 database that can
     be the target of an=20 <edit-config> operation.
     (Writing to = both=20 <candidate> and <running> does not=20 work!)
      * therefore the agent MUST = support the=20 :candidate OR
        = :writable-running=20 capabilities, but not both)
   * the :candidate and = :startup=20 capabilities are independent,
     not mutually=20 exclusive.

(Is there any agreement on these points?)

I = changed my=20 mind on 'minimal <startup> operations'.
I think = <get-config> and=20 <validate> on the "NV version"
are too useful for operators to = leave as=20 optional.
So the table in 4741bis, 8.7.5.1 is OK

I do not like = all the=20 combinations for <copy-config>
that occur when :candidate and = :startup=20 are both supported.
Or for that matter, just=20 :candidate.

8.3.5.1.  <get-config>, = <edit-config>,=20 <copy-config>, and <validate>

   The = candidate=20 configuration can be used as a source or target of any
  =20 <get-config>, <edit-config>, <copy-config>, or=20 <validate> operation
   as a <source> or = <target>=20 parameter.  The <candidate> element is used
   = to=20 indicate the candidate configuration:

This first sentence is = clearly=20 wrong.
You cannot copy from candidate to running.
You can only use = <commit> for that.
(Not sure about copy from candidate to=20 startup.)
You should not be able to copy from running to candidate=20 either.
We have <discard-changes> for that.

I wish we = had time=20 to work on the NETCONF database architecture,
because it isn't very=20 good.

>
> = /martin
>

Andy

------=_NextPart_000_20F5_01CA13C4.B4769AF0-- From bertietf@bwijnen.net Sun Aug 2 14:02: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 1C7043A6C04 for ; Sun, 2 Aug 2009 14:02:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.219 X-Spam-Level: ** X-Spam-Status: No, score=2.219 tagged_above=-999 required=5 tests=[AWL=0.802, BAYES_20=-0.74, 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 cpqBXr+urgPE for ; Sun, 2 Aug 2009 14:02:23 -0700 (PDT) Received: from relay.versatel.net (beverwijk.tele2.vuurwerk.nl [62.250.3.53]) by core3.amsl.com (Postfix) with ESMTP id C2AEF3A6BE0 for ; Sun, 2 Aug 2009 14:02:22 -0700 (PDT) Received: from [87.215.199.34] (helo=BertLaptop) by relay.versatel.net with smtp (Exim 4.69) (envelope-from ) id 1MXiCG-0005IL-Lp; Sun, 02 Aug 2009 23:02:24 +0200 Message-ID: <25F318D5AD464AAB9D884EA06D23FAFC@BertLaptop> From: "Bert Wijnen \(IETF\)" To: "Andy Bierman" , "NETCONF" References: <4A7473F3.5080709@netconfcentral.com> In-Reply-To: <4A7473F3.5080709@netconfcentral.com> Date: Sun, 2 Aug 2009 23:01:50 +0200 Organization: Consultant MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_2131_01CA13C5.3847E000" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Windows Mail 6.0.6001.18000 X-MimeOLE: Produced By Microsoft MimeOLE V6.0.6001.18049 Subject: Re: [Netconf] partial locking for candidate and startup? 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, 02 Aug 2009 21:02:24 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_2131_01CA13C5.3847E000 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I anm not sure if we made that decision explicitly. But I do know that we as a result of discussions/concerns/issues, we = came to this text (as currently in revision 09, which is in IESG review): 2.1.1. Usage Scenarios In the following we describe a few scenarios for partial locking. Partial locking is primarily useful towards the running configuration. However it can be used to lock parts of a candidate datastore as well. While scenarios using the running datastore are seen as the most important, as an example a scenario involving the candidate datastore is also presented. Besides the three described here, there are many other usage scenarios possible. Bert ----- Original Message -----=20 From: Andy Bierman=20 To: NETCONF=20 Sent: Saturday, August 01, 2009 6:57 PM Subject: [Netconf] partial locking for candidate and startup? Hi, Are there any plans to extend the partial locking feature to the candidate and startup databases? The WG has only addressed the 'SQL database model' (write directly to the persistent database). However, there are many networking devices which use the :candidate or :startup capabilities. If so, the partial locking feature is not applicable. It is possible that partial locking for candidate and startup would require too many changes to the protocol. I am just wondering if this decision has already been made or not. Andy _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf -------------------------------------------------------------------------= ----- No virus found in this incoming message. Checked by AVG - www.avg.com=20 Version: 8.5.392 / Virus Database: 270.13.41/2277 - Release Date: = 08/02/09 05:56:00 ------=_NextPart_000_2131_01CA13C5.3847E000 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
I anm not sure if we made that decision=20 explicitly.
But I do know that we as a result of=20 discussions/concerns/issues, we came to
this text (as currently in revision 09, which = is in IESG=20 review):
 
2.1.1.  Usage Scenarios
 
   In the following we describe a few = scenarios for=20 partial locking.
   Partial locking is primarily useful = towards the=20 running
   configuration.  However it can be used to = lock=20 parts of a candidate
   datastore as well.  While = scenarios=20 using the running datastore are
   seen as the most = important, as=20 an example a scenario involving the
   candidate datastore = is also=20 presented.  Besides the three described
   here, there = are=20 many other usage scenarios possible.
 
Bert
----- Original Message -----
From:=20 Andy=20 Bierman
To: NETCONF
Sent: Saturday, August 01, 2009 = 6:57=20 PM
Subject: [Netconf] partial = locking for=20 candidate and startup?

Hi,

Are there any plans to extend the partial=20 locking
feature to the candidate and startup databases?

The = WG has=20 only addressed the 'SQL database model'
(write directly to the = persistent=20 database).

However, there are many networking devices
which = use the=20 :candidate or :startup capabilities.
If so, the partial locking = feature is=20 not applicable.

It is possible that partial locking for=20 candidate
and startup would require too many changes to the = protocol.
I=20 am just wondering if this decision has already been made or=20 = not.



Andy
_____________________________________________= __
Netconf=20 mailing list
Netconf@ietf.org
https://www.ietf.o= rg/mailman/listinfo/netconf


No virus found in this incoming message.
Checked by AVG = - www.avg.com
Version: 8.5.392 / = Virus=20 Database: 270.13.41/2277 - Release Date: 08/02/09=20 05:56:00
------=_NextPart_000_2131_01CA13C5.3847E000-- From andy@netconfcentral.com Sun Aug 2 14:21: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 604D43A6BA7 for ; Sun, 2 Aug 2009 14:21:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.464 X-Spam-Level: X-Spam-Status: No, score=-2.464 tagged_above=-999 required=5 tests=[AWL=0.135, 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 G4D19jB2r48j for ; Sun, 2 Aug 2009 14:21:49 -0700 (PDT) Received: from n17.bullet.mail.mud.yahoo.com (n17.bullet.mail.mud.yahoo.com [68.142.206.144]) by core3.amsl.com (Postfix) with SMTP id 6261C3A693C for ; Sun, 2 Aug 2009 14:21:49 -0700 (PDT) Received: from [68.142.200.221] by n17.bullet.mail.mud.yahoo.com with NNFMP; 02 Aug 2009 21:21:47 -0000 Received: from [68.142.201.252] by t9.bullet.mud.yahoo.com with NNFMP; 02 Aug 2009 21:21:47 -0000 Received: from [127.0.0.1] by omp413.mail.mud.yahoo.com with NNFMP; 02 Aug 2009 21:21:47 -0000 X-Yahoo-Newman-Id: 672249.55565.bm@omp413.mail.mud.yahoo.com Received: (qmail 66640 invoked from network); 2 Aug 2009 21:21:47 -0000 Received: from unknown (HELO ?192.168.0.10?) (andy@67.125.157.61 with plain) by smtp102.sbc.mail.sp1.yahoo.com with SMTP; 2 Aug 2009 21:21:46 -0000 X-YMail-OSG: 6AQpAq4VM1nlmTdbWNdGJNf9fY8thpTHW5o9d0mdnz3elCrvbY8HCQplOlMvbVxdNsHH6RgqlSl1riklrIIWSwGOWVbAaxRjcbNiVx_oDMj8ARLjv3pSrMenpiVEw8ayA8TIAVtNF2bEk3NAOI_se0s2Y.hgdyNf452_LQ080sGXiQAbjEm94gbbUBcrToy6IgrG62b9JYHDZPCYJTleGJs66WexKBUGfsQtRwoxXoN5AWsLUpgvwN8_NRmEwqRX_lrS4EHC.o7GBtCpvShA0nNCNhRUlRuSYIRtpZGr5DSQRQ-- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4A760385.7050708@netconfcentral.com> Date: Sun, 02 Aug 2009 14:22:13 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.22 (X11/20090608) MIME-Version: 1.0 To: "Bert Wijnen (IETF)" References: <4A7473F3.5080709@netconfcentral.com> <25F318D5AD464AAB9D884EA06D23FAFC@BertLaptop> In-Reply-To: <25F318D5AD464AAB9D884EA06D23FAFC@BertLaptop> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: NETCONF Subject: Re: [Netconf] partial locking for candidate and startup? 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, 02 Aug 2009 21:21:50 -0000 Bert Wijnen (IETF) wrote: > I anm not sure if we made that decision explicitly. > But I do know that we as a result of discussions/concerns/issues, we came to > this text (as currently in revision 09, which is in IESG review): > > 2.1.1. Usage Scenarios > > In the following we describe a few scenarios for partial locking. > Partial locking is primarily useful towards the running > configuration. However it can be used to lock parts of a candidate > datastore as well. While scenarios using the running datastore are > seen as the most important, as an example a scenario involving the > candidate datastore is also presented. Besides the three described > here, there are many other usage scenarios possible. > The use case in 2.1.1.3 is a mystery to me. I don't really see the point of locking my little section of the candidate scratchpad, then manually coordinating with all the other users (by email or SMS?) "is it OK to do a commit now?". If even one user doesn't get the memo, and writes to the candidate ignoring all locks, then the edit-config might succeed. This can taint the commit -- either it will fail, or maybe a hacker will get somebody else to issue for some injected data under some other user's credentials. Partial locking does not work for candidate. > Bert Andy > > ----- Original Message ----- > *From:* Andy Bierman > *To:* NETCONF > *Sent:* Saturday, August 01, 2009 6:57 PM > *Subject:* [Netconf] partial locking for candidate and startup? > > Hi, > > Are there any plans to extend the partial locking > feature to the candidate and startup databases? > > The WG has only addressed the 'SQL database model' > (write directly to the persistent database). > > However, there are many networking devices > which use the :candidate or :startup capabilities. > If so, the partial locking feature is not applicable. > > It is possible that partial locking for candidate > and startup would require too many changes to the protocol. > I am just wondering if this decision has already been made or not. > > > > Andy > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf > > ------------------------------------------------------------------------ > > > No virus found in this incoming message. > Checked by AVG - www.avg.com > Version: 8.5.392 / Virus Database: 270.13.41/2277 - Release Date: > 08/02/09 05:56:00 From j.schoenwaelder@jacobs-university.de Mon Aug 3 13: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 7E4B028C273 for ; Mon, 3 Aug 2009 13:22:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.212 X-Spam-Level: X-Spam-Status: No, score=-2.212 tagged_above=-999 required=5 tests=[AWL=0.037, 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 UmkmPTdKlwOx for ; Mon, 3 Aug 2009 13:22:18 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 68DF128C1D3 for ; Mon, 3 Aug 2009 13:22:18 -0700 (PDT) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 2B3E1C0043; Mon, 3 Aug 2009 22:22:04 +0200 (CEST) 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 z6qPcmYCP2Y8; Mon, 3 Aug 2009 22:22:03 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id F1991C0047; Mon, 3 Aug 2009 22:22:02 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id AF284B76EC3; Mon, 3 Aug 2009 22:22:03 +0200 (CEST) Date: Mon, 3 Aug 2009 22:22:03 +0200 From: Juergen Schoenwaelder To: "Bert Wijnen (IETF)" Message-ID: <20090803202203.GA20902@elstar.local> Mail-Followup-To: "Bert Wijnen (IETF)" , David B Harrington , Netconf References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.19 (2009-01-05) Cc: Netconf Subject: Re: [Netconf] Fw: Database Architecture OK or NOT-OK? 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, 03 Aug 2009 20:22:19 -0000 On Sun, Aug 02, 2009 at 10:58:09PM +0200, Bert Wijnen (IETF) wrote: > 8.3.5.1. , , , and > > The candidate configuration can be used as a source or target of any > , , , or operation > as a or parameter. The element is used > to indicate the candidate configuration: > > This first sentence is clearly wrong. > You cannot copy from candidate to running. > You can only use for that. Is this stated somewhere or would a copy-config from candidate to running just be the same as a commit? > (Not sure about copy from candidate to startup.) > You should not be able to copy from running to candidate either. > We have for that. Would a copy-config from running to candidate do exactly what discard-changes does? My question is whether we simply have redundant operations or if we have a problem with similar but slightly different semantics? I personally find copy-config('candidate', 'runnning') nicer than discard-changes() since it tells me which datastores are actually involved - but that might be a matter of personal preference. If both achieve the same effect, lets just state it explicitely and then script writers can choose what they prefer. /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 Mon Aug 3 14:41: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 2C16C3A68D0 for ; Mon, 3 Aug 2009 14:41:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.112 X-Spam-Level: X-Spam-Status: No, score=-5.112 tagged_above=-999 required=5 tests=[AWL=1.486, 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 wOrLAmPj-odN for ; Mon, 3 Aug 2009 14:41:02 -0700 (PDT) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [217.115.75.233]) by core3.amsl.com (Postfix) with ESMTP id B268F3A6ADE for ; Mon, 3 Aug 2009 14:41:01 -0700 (PDT) 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 n73Lf2KN030259 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 3 Aug 2009 23:41:02 +0200 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 n73Lf1DA024421; Mon, 3 Aug 2009 23:41:01 +0200 Received: from DEMUEXC005.nsn-intra.net ([10.150.128.17]) by demuexc024.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Mon, 3 Aug 2009 23:41:00 +0200 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_01CA1483.1773E029" Date: Mon, 3 Aug 2009 23:40:59 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Summary of action items, decisions, etc. from the NETCONF session Thread-Index: AcoUgxbltTySn/K6TYWP9O85vFfcfQ== From: "Ersue, Mehmet (NSN - DE/Munich)" To: X-OriginalArrivalTime: 03 Aug 2009 21:41:00.0890 (UTC) FILETIME=[17F84BA0:01CA1483] Subject: [Netconf] Summary of action items, decisions, etc. from the 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, 03 Aug 2009 21:41:03 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CA1483.1773E029 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dear NETCONF WG, please find below a short summary and action items from the NETCONF WG session on July 28, 2009: - We had 37 participants in the 2 hour NETCONF session. Partial Lock RPC: - Partial Lock RPC for NETCONF is planned to bring to IESG chat on August 13, 2009. Bert will keep shepherding. NETCONF Monitoring: - Juergen to check, whether the IP address types are consistent with yang-types and to notify the WG maillist. - The WG decided not to wait on YANG and to bring the NETCONF Monitoring draft to IETF LC with XSD model as normative. =20 - Mehmet to prepare a document write-up. NETCONF 4741bis: - Different issues have been discussed and decided during the session. Martin to bring the result and open issues to the maillist. With-defaults capability: - There was some discussion on remaining issues.=20 - A WGLC will be started to discuss them and additional issues further. Mehmet to start a WGLC. Robust Configuration Management: - Bob Cole presented on the not-chartered draft "Robust Configuration Management within NETCONF".=20 - The sense in the room was positive however there was not sufficient support to adopt it as a WG item at present. - Bob to address raised concerns and to trigger the discussion on NETCONF maillist with a document update. Chairs to check the sense of the WG on following issues and possible new work: - 4742bis or clarifications - NETCONF database architecture - Access control Cheers, Bert & Mehmet ------_=_NextPart_001_01CA1483.1773E029 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Summary of action items, decisions, etc. from the NETCONF = session

Dear NETCONF WG,

please find below a short summary and = action items from the NETCONF WG session on July 28, 2009:

- We had 37 participants in the 2 = hour NETCONF session.

Partial Lock RPC:
- Partial Lock RPC for NETCONF is = planned to bring to IESG chat on August 13, 2009. Bert will keep = shepherding.

NETCONF Monitoring:
- Juergen to check, whether the IP = address types are consistent with yang-types and to notify the WG = maillist.
- The WG decided not to wait on YANG = and to bring the NETCONF Monitoring draft to IETF LC with XSD model as = normative. 

- Mehmet to prepare a document = write-up.

NETCONF 4741bis:
- Different issues have been = discussed and decided during the session. Martin to bring the result and = open issues to the maillist.

With-defaults capability:
- There was some discussion on = remaining issues.
- A WGLC will be started to discuss = them and additional issues further. Mehmet to start a WGLC.

Robust Configuration = Management:
- Bob Cole presented on the = not-chartered draft "Robust Configuration Management within = NETCONF".
- The sense in the room was positive = however there was not sufficient support to adopt it as a WG item at = present.
- Bob to address raised concerns and = to trigger the discussion on NETCONF maillist with a document = update.

Chairs to check the sense of the WG = on following issues and possible new work:
- 4742bis or clarifications
- NETCONF database = architecture
- Access control

Cheers,
Bert & Mehmet

------_=_NextPart_001_01CA1483.1773E029-- From mehmet.ersue@nsn.com Mon Aug 3 14:41: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 2CE6C3A6D6F for ; Mon, 3 Aug 2009 14:41:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.247 X-Spam-Level: X-Spam-Status: No, score=-5.247 tagged_above=-999 required=5 tests=[AWL=1.351, 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 AQRCh7-DceA2 for ; Mon, 3 Aug 2009 14:41:36 -0700 (PDT) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [217.115.75.233]) by core3.amsl.com (Postfix) with ESMTP id 95D903A69A2 for ; Mon, 3 Aug 2009 14:41:36 -0700 (PDT) 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 n73LfZVD030549 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 3 Aug 2009 23:41:35 +0200 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 n73LfYLU025243; Mon, 3 Aug 2009 23:41:35 +0200 Received: from DEMUEXC005.nsn-intra.net ([10.150.128.17]) by demuexc024.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Mon, 3 Aug 2009 23:41:34 +0200 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_01CA1483.2BC8740A" Date: Mon, 3 Aug 2009 23:41:33 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: WGLC: draft-ietf-netconf-with-defaults-02 Thread-Index: AcoUgyuJ47jU9+92T5OLXvtBt49u7Q== From: "Ersue, Mehmet (NSN - DE/Munich)" To: X-OriginalArrivalTime: 03 Aug 2009 21:41:34.0139 (UTC) FILETIME=[2BC9B0B0:01CA1483] Subject: [Netconf] WGLC: draft-ietf-netconf-with-defaults-02 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, 03 Aug 2009 21:41:38 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CA1483.2BC8740A Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dear NETCONF WG,=20 we had a good progress on the draft "With-defaults capability=20 for NETCONF". In the NETCONF session at IETF we decided to=20 bring the draft to WGLC to initiate additional discussion. With this mail we start a WGLC for the "With-defaults capability=20 for NETCONF" draft, which is planned to publish as a Proposed=20 Standard RFC. The WGLC will run until August 21, 2009.=20 Everybody on the NETCONF WG maillist PLEASE REVIEW the=20 draft and send your comments to the NETCONF maillist.=20 (http://tools.ietf.org/html/draft-ietf-netconf-with-defaults-02)=20 Thank you and looking forward for your comments.=20 Cheers,=20 Mehmet=20 ------_=_NextPart_001_01CA1483.2BC8740A Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable WGLC: draft-ietf-netconf-with-defaults-02

Dear NETCONF WG,

we had a good progress on the draft = "With-defaults capability
for NETCONF". In the NETCONF = session at IETF we decided to
bring the draft to WGLC to initiate = additional discussion.

With this mail we start a WGLC for = the "With-defaults capability
for NETCONF" draft, which is = planned to publish as a Proposed
Standard RFC. The WGLC will run = until August 21, 2009.

Everybody on the NETCONF WG maillist = PLEASE REVIEW the
draft and send your comments to the = NETCONF maillist.
(<= U>http://tools.ietf.org/html/draft-ietf-netconf-with-defau= lts-02)

Thank you and looking forward for = your comments.

Cheers,
Mehmet

------_=_NextPart_001_01CA1483.2BC8740A-- From andy@netconfcentral.com Mon Aug 3 16:32: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 662753A6A39 for ; Mon, 3 Aug 2009 16:32:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.471 X-Spam-Level: X-Spam-Status: No, score=-2.471 tagged_above=-999 required=5 tests=[AWL=0.128, 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 snCJ7W8noThw for ; Mon, 3 Aug 2009 16:32:40 -0700 (PDT) Received: from smtp102.sbc.mail.mud.yahoo.com (smtp102.sbc.mail.mud.yahoo.com [68.142.198.201]) by core3.amsl.com (Postfix) with SMTP id 8BCDE3A6A91 for ; Mon, 3 Aug 2009 16:32:40 -0700 (PDT) Received: (qmail 30529 invoked from network); 3 Aug 2009 23:32:41 -0000 Received: from unknown (HELO ?192.168.0.10?) (andy@67.125.157.61 with plain) by smtp102.sbc.mail.mud.yahoo.com with SMTP; 3 Aug 2009 23:32:41 -0000 X-YMail-OSG: .FUN6_0VM1lzpQJi.9N0TjL7I7RcSL.c7JjPrPw4yHfspisNEncHnr2_VBXljbwxfT2uFSp.OHkpchtq_z0QImKAwL0VlRrzctiosJeiIjbXdhHd7kh00adNpiDq223u8_TqoaBBc.i.UHryZZgl7ms.Rm01fYp81gXo7zmwmyRWqzKuJLzyvUtyGXrRpoJ6jpFc2NBFZZiwn0t._h.Dp_p0JWwzlGuBaZNJtOIIyVE3UoEleVrcwlDKY1UzsLzG7bHmtf5FhmUTyeA- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4A7773BB.1080206@netconfcentral.com> Date: Mon, 03 Aug 2009 16:33:15 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.22 (X11/20090608) MIME-Version: 1.0 To: "Bert Wijnen (IETF)" , David B Harrington , Netconf References: <20090803202203.GA20902@elstar.local> In-Reply-To: <20090803202203.GA20902@elstar.local> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [Netconf] Fw: Database Architecture OK or NOT-OK? 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, 03 Aug 2009 23:32:41 -0000 Juergen Schoenwaelder wrote: > On Sun, Aug 02, 2009 at 10:58:09PM +0200, Bert Wijnen (IETF) wrote: > >> 8.3.5.1. , , , and >> >> The candidate configuration can be used as a source or target of any >> , , , or operation >> as a or parameter. The element is used >> to indicate the candidate configuration: >> >> This first sentence is clearly wrong. >> You cannot copy from candidate to running. >> You can only use for that. > > Is this stated somewhere or would a copy-config from candidate to > running just be the same as a commit? > It should be stated that they are equivalent. >> (Not sure about copy from candidate to startup.) >> You should not be able to copy from running to candidate either. >> We have for that. > > Would a copy-config from running to candidate do exactly what > discard-changes does? My question is whether we simply have redundant > operations or if we have a problem with similar but slightly different > semantics? yes -- that is what at least 2 implementations do. > > I personally find copy-config('candidate', 'runnning') nicer than > discard-changes() copy from running to candidate --> discard-changes copy from candidate to running --> commit commit has extra parameters for confirmed commit. a copy-config does not count as the 2nd commit in a confirmed-commit. Not sure what happens to the confirmed commit in progress if running is touched via copy-config. IMO, :candidate and :writable-running do not work together. They almost work together, and only go horribly wrong sometimes. If that's good enough for the NETCONF database architecture, then I guess there is nothing to fix. since it tells me which datastores are actually > involved - but that might be a matter of personal preference. If both > achieve the same effect, lets just state it explicitely and then > script writers can choose what they prefer. > > /js > Andy From mehmet.ersue@nsn.com Tue Aug 4 02:47: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 932A03A6FF5 for ; Tue, 4 Aug 2009 02:47:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.46 X-Spam-Level: X-Spam-Status: No, score=-2.46 tagged_above=-999 required=5 tests=[AWL=-1.661, BAYES_00=-2.599, J_CHICKENPOX_26=0.6, J_CHICKENPOX_64=0.6, J_CHICKENPOX_65=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 xKGgcoohmfz8 for ; Tue, 4 Aug 2009 02:47:55 -0700 (PDT) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [217.115.75.234]) by core3.amsl.com (Postfix) with ESMTP id 757103A6FC7 for ; Tue, 4 Aug 2009 02:47:55 -0700 (PDT) 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 n749lqud004839 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 4 Aug 2009 11:47:52 +0200 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 n749lmFo015355; Tue, 4 Aug 2009 11:47:52 +0200 Received: from DEMUEXC005.nsn-intra.net ([10.150.128.17]) by demuexc024.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 4 Aug 2009 11:47:49 +0200 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, 4 Aug 2009 11:47:46 +0200 Message-ID: In-Reply-To: <20090731.165452.179797677.mbj@tail-f.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Netconf] Comments on draft-ietf-netconf-monitoring-06.txt Thread-Index: AcoR7uAmWR4rc/u7SuWzGPSwKRqy+AC92mqA References: <200907301232.n6UCWNC7043144@idle.juniper.net> <20090731.165452.179797677.mbj@tail-f.com> From: "Ersue, Mehmet (NSN - DE/Munich)" To: "ext Martin Bjorklund" , , "ext Andy Bierman" , "ext Mark Scott" X-OriginalArrivalTime: 04 Aug 2009 09:47:49.0333 (UTC) FILETIME=[A0A0A050:01CA14E8] Cc: netconf@ietf.org Subject: Re: [Netconf] Comments on draft-ietf-netconf-monitoring-06.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: Tue, 04 Aug 2009 09:47:56 -0000 Hi, thanks to Phil for useful comments, see below. Cheers, Mehmet =20 > -----Original Message----- > From: netconf-bounces@ietf.org=20 > [mailto:netconf-bounces@ietf.org] On Behalf Of ext Martin Bjorklund > Sent: Friday, July 31, 2009 4:55 PM > To: phil@juniper.net > Cc: netconf@ietf.org > Subject: Re: [Netconf] Comments on=20 > draft-ietf-netconf-monitoring-06.txt >=20 > Phil Shafer wrote: > > 2. XML Schema to Monitor NETCONF > >=20 > > s/XML Schema to Monitor NETCONF/Information Model/ > >=20 > > Or is "Data Model"? Ask Juergen. >=20 > Data Model. I would suggest to s/XML Schema to Monitor NETCONF/Data Model used to Monitor NETCONF/ =20 > > The URI ends on ":state". If this is the "NETCONF=20 > Monitoring Schema", > > this should be ":monitor". It also should include a version number: > >=20 > > urn:ietf:params:xml:ns:netconf:monitor:1.0 >=20 > s/state/monitor is fine with me, but I don't agree we should add a > version number. We have the revision statement in YANG modules to > handle versioning. I think both approaches work. My personal preference=20 would be to stick to the approach already discussed=20 in the maillist.=20 > > 2.1 The /netconf-state Subtree > >=20 > > There are two "big picture" questions here: > >=20 > > (a) should ietf models be under a top-level "/ietf/" container? > > We should have some hierarchy in our hierarchical data models. > > If fact should this be under "/ietf/management/netconf"? >=20 > As Andy said this has been discussed and resolved before. Adding this > hierarchy would just add unnecessay containers. The namespace URI > provides the context for the top-level node. >=20 > > (b) Why is there a "-state" suffix? Most of this isn't state data, > > per se (schemas are not state data). It seems like you need to > > separate this. But there is also some question about who we will > > organize data. There are many advocates of intermixing state data > > without the same tree as configuration data, so config=3Dfalse nodes > > will intermix with config=3Dtrue ones. I'm not convinced that this > > works well, but it's something we need to think about for=20 > this draft. >=20 > The model in this draft does not mix config and state, so I am not > sure what we need to think about? >=20 > > 2.1.3. The /netconf-state/schemas Subtree > >=20 > > Why isn't "namespace" the key, instead of identifier? >=20 > The current indexing allows you to list (and fetch) YANG submodules > (and equivalent for XSD and RNG). >=20 > > Shouldn't "version" be "revision"? This is the right name for > > YANG. What does "version" mean for XSD? The version has typically > > been part of the namespace. I agree with Andy. The data model is not YANG-only and=20 the terminology should be more generic. =20 > In XSD, there is a 'version' attribute on the xs:schema element. > Some XML schemas use that, and some encode the version in the URI. >=20 > This leaf needs a data model mapping. We should add text that says > that for YANG modules and submodules, this leaf contains the > (sub)module's revision. Agree, we should add text and highlight what the leaf=20 contains in a YANG module. =20 > > 2.1.5. The /netconf-state/statistics Subtree > >=20 > > "Statistical data pertaining to the NETCONF server" implies=20 > that there > > is only one server. Given that most of us will be using the openssh > > code and the sshd_conf subsystem hook, there's not one=20 > single server. > >=20 > > In particular, start-time makes no sense. >=20 > Maybe it should say "network management subsystem" or something, like > sysUpTime. >=20 > > 3.1. The Operation > >=20 > > s/When/If/ > > s/this new operation/the operation/ > >=20 > > The namespace should be the key here. Also s/version/revision/ > >=20 > > The 'data-missing' error code sounds misleading. If the client asks > > for something that we don't have, it's a problem with the=20 > client. We > > should return invalid-value or something like that. >=20 > 'invalid-value' is fine, assuming that 'data-missing' MUST only be > used for errors coupled to data store content. 'invalid-value' looks fine.=20 =20 > /martin > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf >=20 From Washam.Fan@huaweisymantec.com Tue Aug 4 02:51: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 40F3228C278 for ; Tue, 4 Aug 2009 02:51:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.021 X-Spam-Level: X-Spam-Status: No, score=-1.021 tagged_above=-999 required=5 tests=[AWL=-0.526, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8PSZ0253g10C for ; Tue, 4 Aug 2009 02:51:51 -0700 (PDT) Received: from mta1.huaweisymantec.com (unknown [218.17.155.14]) by core3.amsl.com (Postfix) with ESMTP id 6B02928C202 for ; Tue, 4 Aug 2009 02:51:51 -0700 (PDT) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-disposition: inline Content-type: text/plain; charset=us-ascii Received: from hstml01-in.huaweisymantec.com ([172.26.3.41]) by hstga01-in.huaweisymantec.com (Sun Java(tm) System Messaging Server 6.3-8.03 (built Apr 24 2009; 32bit)) with ESMTP id <0KNU00J4CJE7QZ00@hstga01-in.huaweisymantec.com> for netconf@ietf.org; Tue, 04 Aug 2009 17:51:43 +0800 (CST) Received: from huaweisymantec.com ([127.0.0.1]) by hstml01-in.huaweisymantec.com (Sun Java(tm) System Messaging Server 6.3-8.03 (built Apr 24 2009; 32bit)) with ESMTP id <0KNU00ETHJE7M710@hstml01-in.huaweisymantec.com> for netconf@ietf.org; Tue, 04 Aug 2009 17:51:43 +0800 (CST) Received: from [10.27.154.141] by hstml01-in.huaweisymantec.com (mshttpd); Tue, 04 Aug 2009 17:51:43 +0800 From: WashamFan To: Andy Bierman Message-id: Date: Tue, 04 Aug 2009 17:51:43 +0800 X-Mailer: Sun Java(tm) System Messenger Express 6.3-8.03 (built Apr 24 2009; 32bit) Content-language: en X-Accept-Language: en Priority: normal In-reply-to: <4A732066.5060204@netconfcentral.com> References: <4A71E502.8020107@netconfcentral.com> <200907302317.n6UNHG4e047796@idle.juniper.net> <20090731.170924.62921357.mbj@tail-f.com> <4A732066.5060204@netconfcentral.com> Cc: netconf@ietf.org Subject: Re: [Netconf] lock and commit operations 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, 04 Aug 2009 09:51:52 -0000 Hi, I agreed with Martin, letting lock on candidate control breaks the sematics of lock. Why we just constrain the behavior of in 8.3.4.1 stating like: can't take effect the changes in either candidate or running is locked. washam ----- Original Message ----- From: Andy Bierman Date: Saturday, August 1, 2009 0:50 am Subject: Re: [Netconf] lock and commit operations To: Martin Bjorklund Cc: netconf@ietf.org > Martin Bjorklund wrote: > > [resend] > > > > Phil Shafer wrote: > >> Andy Bierman writes: > >>> Does the lock on candidate have any affect on ? > >> Absolutely. The lock on config controls the commit. > > > > This is not obvious so it needs clarification. does not > > modify the candidate, so why does a lock on candidate prevent me from > > committing? If running is locked it is obvious since running will > be > > modified by the commit. > > > > Agreed. It is obvious a lock on the running config should stop > a commit. Candidate is not obvious at all because it should > never change (OK or error) because of commit. > > I am wondering if 'running' is the only lock that should prevent a commit. > > The lock on candidate should prevent edit-config, delete-config, > copy-config, and discard-changes. > > > > > > /martin > > > > Andy > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf > From Washam.Fan@huaweisymantec.com Tue Aug 4 02:56:04 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 A625A3A6FF9 for ; Tue, 4 Aug 2009 02:56:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.084 X-Spam-Level: X-Spam-Status: No, score=0.084 tagged_above=-999 required=5 tests=[AWL=-1.280, BAYES_20=-0.74, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GuRYQU5+bOmA for ; Tue, 4 Aug 2009 02:56:04 -0700 (PDT) Received: from mta2.huaweisymantec.com (unknown [218.17.155.15]) by core3.amsl.com (Postfix) with ESMTP id C0CC73A6D0A for ; Tue, 4 Aug 2009 02:56:03 -0700 (PDT) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-disposition: inline Content-type: text/plain; charset=us-ascii Received: from hstml01-in.huaweisymantec.com ([172.26.3.42]) by hstga02-in.huaweisymantec.com (Sun Java(tm) System Messaging Server 6.3-8.03 (built Apr 24 2009; 32bit)) with ESMTP id <0KNU00730JL5WH70@hstga02-in.huaweisymantec.com> for netconf@ietf.org; Tue, 04 Aug 2009 17:55:53 +0800 (CST) Received: from huaweisymantec.com ([127.0.0.1]) by hstml01-in.huaweisymantec.com (Sun Java(tm) System Messaging Server 6.3-8.03 (built Apr 24 2009; 32bit)) with ESMTP id <0KNU00ESEJL5M910@hstml01-in.huaweisymantec.com> for netconf@ietf.org; Tue, 04 Aug 2009 17:55:53 +0800 (CST) Received: from [10.27.154.141] by hstml01-in.huaweisymantec.com (mshttpd); Tue, 04 Aug 2009 17:55:53 +0800 From: WashamFan To: Andy Bierman Message-id: Date: Tue, 04 Aug 2009 17:55:53 +0800 X-Mailer: Sun Java(tm) System Messenger Express 6.3-8.03 (built Apr 24 2009; 32bit) Content-language: en X-Accept-Language: en Priority: normal In-reply-to: <4A71CD21.6040909@netconfcentral.com> References: <4A71CD21.6040909@netconfcentral.com> Cc: NETCONF Subject: Re: [Netconf] lock and commit operations 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, 04 Aug 2009 09:56:04 -0000 > A careful reading of 4741bis, sec. 7.5, para 4 reveals > that the the "candidate" portion of the database architecture > is seriously broken. > > The operation does not affect the operation at all. > Martin already pointed this out. Even if I lock every database > on the box, anybody can just login at anytime and issue , > and ruin the 'database transaction' I am trying to complete. > (Note the quotes, as to not offend any database experts > out there who know NETCONF does not support real transactions.) > > If I am doing a confirmed-commit, anybody who logs in and invokes > will confirm my commit, instead of letting me decide > to keep or cancel the recent changes to running. > Even though I have every database globally locked. > > Since does not work on the candidate database at all, > there is no need to worry about how works with partial locking. I am afraid draft partial-lock does not preclude the candidate scenario, please see 2.1.1.3 washam > I don't think a :confirmed-commit.1.1 capability can fix > all these problems. > > > Andy > > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf > From j.schoenwaelder@jacobs-university.de Tue Aug 4 02:56: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 051E93A6E61 for ; Tue, 4 Aug 2009 02:56:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.213 X-Spam-Level: X-Spam-Status: No, score=-2.213 tagged_above=-999 required=5 tests=[AWL=0.036, 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 4Gbv7vyHfpZc for ; Tue, 4 Aug 2009 02:56:38 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 8F2F83A6B8E for ; Tue, 4 Aug 2009 02:56:37 -0700 (PDT) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id CBED4C004E; Tue, 4 Aug 2009 11:56:39 +0200 (CEST) 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 ZZ6jUENMjnQx; Tue, 4 Aug 2009 11:56:38 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 6D8B2C0049; Tue, 4 Aug 2009 11:56:38 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 33357B776E2; Tue, 4 Aug 2009 11:56:39 +0200 (CEST) Date: Tue, 4 Aug 2009 11:56:39 +0200 From: Juergen Schoenwaelder To: Andy Bierman Message-ID: <20090804095639.GA21611@elstar.local> Mail-Followup-To: Andy Bierman , "Bert Wijnen (IETF)" , David B Harrington , Netconf References: <20090803202203.GA20902@elstar.local> <4A7773BB.1080206@netconfcentral.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4A7773BB.1080206@netconfcentral.com> User-Agent: Mutt/1.5.19 (2009-01-05) Cc: Netconf Subject: Re: [Netconf] Fw: Database Architecture OK or NOT-OK? 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, 04 Aug 2009 09:56:39 -0000 On Tue, Aug 04, 2009 at 01:33:15AM +0200, Andy Bierman wrote: > IMO, :candidate and :writable-running do not work > together. They almost work together, and only go horribly wrong > sometimes. If that's good enough for the NETCONF > database architecture, then I guess there is nothing to fix. The case where a running timed commit interferes with an edit-config('running', ...) can probably be fixed by letting any attempts to change running fail while a commit is in progress. Are there other things that can go horribly wrong? /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From Washam.Fan@huaweisymantec.com Tue Aug 4 03:40: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 87E6F3A67EC for ; Tue, 4 Aug 2009 03:40:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.526 X-Spam-Level: X-Spam-Status: No, score=-0.526 tagged_above=-999 required=5 tests=[AWL=-0.031, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G3zTh36gwq9m for ; Tue, 4 Aug 2009 03:40:13 -0700 (PDT) Received: from mta2.huaweisymantec.com (unknown [218.17.155.15]) by core3.amsl.com (Postfix) with ESMTP id E725E3A7019 for ; Tue, 4 Aug 2009 03:39:24 -0700 (PDT) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-disposition: inline Content-type: text/plain; charset=us-ascii Received: from hstml01-in.huaweisymantec.com ([172.26.3.42]) by hstga02-in.huaweisymantec.com (Sun Java(tm) System Messaging Server 6.3-8.03 (built Apr 24 2009; 32bit)) with ESMTP id <0KNU007K7LLGWH70@hstga02-in.huaweisymantec.com> for netconf@ietf.org; Tue, 04 Aug 2009 18:39:17 +0800 (CST) Received: from huaweisymantec.com ([127.0.0.1]) by hstml01-in.huaweisymantec.com (Sun Java(tm) System Messaging Server 6.3-8.03 (built Apr 24 2009; 32bit)) with ESMTP id <0KNU00EW5LLGM710@hstml01-in.huaweisymantec.com> for netconf@ietf.org; Tue, 04 Aug 2009 18:39:16 +0800 (CST) Received: from [10.27.154.141] by hstml01-in.huaweisymantec.com (mshttpd); Tue, 04 Aug 2009 18:39:16 +0800 From: WashamFan To: Juergen Schoenwaelder Message-id: Date: Tue, 04 Aug 2009 18:39:16 +0800 X-Mailer: Sun Java(tm) System Messenger Express 6.3-8.03 (built Apr 24 2009; 32bit) Content-language: en X-Accept-Language: en Priority: normal In-reply-to: <20090804095639.GA21611@elstar.local> References: <20090803202203.GA20902@elstar.local> <4A7773BB.1080206@netconfcentral.com> <20090804095639.GA21611@elstar.local> Cc: Netconf Subject: Re: [Netconf] Fw: Database Architecture OK or NOT-OK? 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, 04 Aug 2009 10:40:14 -0000 Hi, ----- Original Message ----- From: Juergen Schoenwaelder Date: Tuesday, August 4, 2009 5:56 pm Subject: Re: [Netconf] Fw: Database Architecture OK or NOT-OK? To: Andy Bierman Cc: Netconf > On Tue, Aug 04, 2009 at 01:33:15AM +0200, Andy Bierman wrote: > > > IMO, :candidate and :writable-running do not work > > together. They almost work together, and only go horribly wrong > > sometimes. If that's good enough for the NETCONF > > database architecture, then I guess there is nothing to fix. > > The case where a running timed commit interferes with an > edit-config('running', ...) can probably be fixed by letting any > attempts to change running fail while a commit is in > progress. But changes are allowed before comfirming commit. washam > Are there other things that can go horribly wrong? > > /js > > -- > 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 Washam.Fan@huaweisymantec.com Tue Aug 4 04: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 CE2193A69BE for ; Tue, 4 Aug 2009 04:12:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.52 X-Spam-Level: X-Spam-Status: No, score=-0.52 tagged_above=-999 required=5 tests=[AWL=-0.025, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O3peRW+E4KbK for ; Tue, 4 Aug 2009 04:12:32 -0700 (PDT) Received: from mta2.huaweisymantec.com (unknown [218.17.155.15]) by core3.amsl.com (Postfix) with ESMTP id 01E913A6FCB for ; Tue, 4 Aug 2009 04:12:32 -0700 (PDT) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-disposition: inline Content-type: text/plain; charset=us-ascii Received: from hstml01-in.huaweisymantec.com ([172.26.3.42]) by hstga02-in.huaweisymantec.com (Sun Java(tm) System Messaging Server 6.3-8.03 (built Apr 24 2009; 32bit)) with ESMTP id <0KNU007VVN3RWH70@hstga02-in.huaweisymantec.com> for netconf@ietf.org; Tue, 04 Aug 2009 19:11:51 +0800 (CST) Received: from huaweisymantec.com ([127.0.0.1]) by hstml01-in.huaweisymantec.com (Sun Java(tm) System Messaging Server 6.3-8.03 (built Apr 24 2009; 32bit)) with ESMTP id <0KNU00FTYN3R8U10@hstml01-in.huaweisymantec.com> for netconf@ietf.org; Tue, 04 Aug 2009 19:11:51 +0800 (CST) Received: from [10.27.154.141] by hstml01-in.huaweisymantec.com (mshttpd); Tue, 04 Aug 2009 19:11:51 +0800 From: WashamFan To: Andy Bierman Message-id: Date: Tue, 04 Aug 2009 19:11:51 +0800 X-Mailer: Sun Java(tm) System Messenger Express 6.3-8.03 (built Apr 24 2009; 32bit) Content-language: en X-Accept-Language: en Priority: normal In-reply-to: <4A71D2E9.4080004@netconfcentral.com> References: <4A71D2E9.4080004@netconfcentral.com> Cc: NETCONF Subject: Re: [Netconf] with-defaults clarification 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, 04 Aug 2009 11:12:32 -0000 Hi, ----- Original Message ----- From: Andy Bierman Date: Friday, July 31, 2009 1:07 am Subject: [Netconf] with-defaults clarification To: NETCONF > Hi, > > I think the with-defaults draft should be clarified to > indicate that the parameter is ignored > for if the target of the copy operation > is the candidate or running databases. What does "ignored" herein exactly mean? How to handle default data if we "ignored" ? As discussed in subsequent mails, it is up to operator to decide how to handle the defaults, so why bother to dictate operator should ignore or comply with the ? washam > Andy > > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf > From j.schoenwaelder@jacobs-university.de Tue Aug 4 04:45: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 CB3DE28C386 for ; Tue, 4 Aug 2009 04:45:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.214 X-Spam-Level: X-Spam-Status: No, score=-2.214 tagged_above=-999 required=5 tests=[AWL=0.035, 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 AHTi14gGZ44A for ; Tue, 4 Aug 2009 04:45:30 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 7C04E28C34D for ; Tue, 4 Aug 2009 04:45:23 -0700 (PDT) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id E36CBC0026; Tue, 4 Aug 2009 13:45:25 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius1.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 5YhkwvZM36lo; Tue, 4 Aug 2009 13:45:25 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 40D94C0024; Tue, 4 Aug 2009 13:45:25 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 22432B779EE; Tue, 4 Aug 2009 13:45:26 +0200 (CEST) Date: Tue, 4 Aug 2009 13:45:26 +0200 From: Juergen Schoenwaelder To: WashamFan Message-ID: <20090804114526.GB21708@elstar.local> Mail-Followup-To: WashamFan , Andy Bierman , Netconf References: <20090803202203.GA20902@elstar.local> <4A7773BB.1080206@netconfcentral.com> <20090804095639.GA21611@elstar.local> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.19 (2009-01-05) Cc: Netconf Subject: Re: [Netconf] Fw: Database Architecture OK or NOT-OK? 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, 04 Aug 2009 11:45:31 -0000 On Tue, Aug 04, 2009 at 12:39:16PM +0200, WashamFan wrote: > But changes are allowed before comfirming commit. I guess so, although such changes will be purged by the commit operation, unless the commit fails and there is an automatic rollback. The point is I think to disallow changes you can't rollback to if the commit fails. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From Washam.Fan@huaweisymantec.com Tue Aug 4 05:26: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 9F1FF3A6FD3 for ; Tue, 4 Aug 2009 05:26:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.229 X-Spam-Level: X-Spam-Status: No, score=0.229 tagged_above=-999 required=5 tests=[AWL=-0.765, BAYES_05=-1.11, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OZ2maI8TtdGA for ; Tue, 4 Aug 2009 05:26:11 -0700 (PDT) Received: from mta1.huaweisymantec.com (unknown [218.17.155.14]) by core3.amsl.com (Postfix) with ESMTP id EAFCC3A6BEA for ; Tue, 4 Aug 2009 05:26:00 -0700 (PDT) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-disposition: inline Content-type: text/plain; charset=us-ascii Received: from hstml01-in.huaweisymantec.com ([172.26.3.41]) by hstga01-in.huaweisymantec.com (Sun Java(tm) System Messaging Server 6.3-8.03 (built Apr 24 2009; 32bit)) with ESMTP id <0KNU00JNWQJ5QZ10@hstga01-in.huaweisymantec.com> for netconf@ietf.org; Tue, 04 Aug 2009 20:25:53 +0800 (CST) Received: from huaweisymantec.com ([127.0.0.1]) by hstml01-in.huaweisymantec.com (Sun Java(tm) System Messaging Server 6.3-8.03 (built Apr 24 2009; 32bit)) with ESMTP id <0KNU00FXSQJ48U10@hstml01-in.huaweisymantec.com> for netconf@ietf.org; Tue, 04 Aug 2009 20:25:52 +0800 (CST) Received: from [10.27.154.141] by hstml01-in.huaweisymantec.com (mshttpd); Tue, 04 Aug 2009 20:25:52 +0800 From: WashamFan To: Juergen Schoenwaelder Message-id: Date: Tue, 04 Aug 2009 20:25:52 +0800 X-Mailer: Sun Java(tm) System Messenger Express 6.3-8.03 (built Apr 24 2009; 32bit) Content-language: en X-Accept-Language: en Priority: normal In-reply-to: <20090804114526.GB21708@elstar.local> References: <20090803202203.GA20902@elstar.local> <4A7773BB.1080206@netconfcentral.com> <20090804095639.GA21611@elstar.local> <20090804114526.GB21708@elstar.local> Cc: Netconf Subject: Re: [Netconf] Fw: Database Architecture OK or NOT-OK? 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, 04 Aug 2009 12:26:11 -0000 Hi, > > But changes are allowed before comfirming commit. > > I guess so, although such changes will be purged by the commit > operation, unless the commit fails and there is an automatic > rollback. The point is I think to disallow changes you can't > rollback to if the commit fails. That depends on how you see the changes between commits. If you consider these changes as an additional part of previous undone changes, then they can be rollbacked. washam From j.schoenwaelder@jacobs-university.de Tue Aug 4 05:45: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 B993928C3DD for ; Tue, 4 Aug 2009 05:45:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.214 X-Spam-Level: X-Spam-Status: No, score=-2.214 tagged_above=-999 required=5 tests=[AWL=0.035, 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 o3v3p4DQLQ06 for ; Tue, 4 Aug 2009 05:45:20 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 496E728C3EC for ; Tue, 4 Aug 2009 05:44:21 -0700 (PDT) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id B2BCAC002B; Tue, 4 Aug 2009 14:44:23 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius1.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id Jz6XKiLSgHmF; Tue, 4 Aug 2009 14:44:23 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id D6C13C0024; Tue, 4 Aug 2009 14:44:21 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id C83D2B77E2A; Tue, 4 Aug 2009 14:44:20 +0200 (CEST) Date: Tue, 4 Aug 2009 14:44:20 +0200 From: Juergen Schoenwaelder To: WashamFan Message-ID: <20090804124420.GA534@elstar.local> Mail-Followup-To: WashamFan , Andy Bierman , Netconf References: <20090803202203.GA20902@elstar.local> <4A7773BB.1080206@netconfcentral.com> <20090804095639.GA21611@elstar.local> <20090804114526.GB21708@elstar.local> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.19 (2009-01-05) Cc: Netconf Subject: Re: [Netconf] Fw: Database Architecture OK or NOT-OK? 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, 04 Aug 2009 12:45:21 -0000 On Tue, Aug 04, 2009 at 02:25:52PM +0200, WashamFan wrote: > Hi, > > > > But changes are allowed before comfirming commit. > > > > I guess so, although such changes will be purged by the commit > > operation, unless the commit fails and there is an automatic > > rollback. The point is I think to disallow changes you can't > > rollback to if the commit fails. > > That depends on how you see the changes between commits. If you > consider these changes as an additional part of previous undone changes, > then they can be rollbacked. Not sure I understand your point. My model is that the start of a commit() defines the running configuration you roll back to if the commit fails. If this model is right, then any further changes to the running configuration after the start of the commit() will be lost - either because the commit succeeds or there is a rollback. /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 Tue Aug 4 06:50: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 4F83D3A6ABD for ; Tue, 4 Aug 2009 06:50:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.475 X-Spam-Level: X-Spam-Status: No, score=-2.475 tagged_above=-999 required=5 tests=[AWL=0.124, 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 8uH8fC3ucB2R for ; Tue, 4 Aug 2009 06:50:07 -0700 (PDT) Received: from smtp106.sbc.mail.mud.yahoo.com (smtp106.sbc.mail.mud.yahoo.com [68.142.198.205]) by core3.amsl.com (Postfix) with SMTP id 4E03F3A6A15 for ; Tue, 4 Aug 2009 06:50:07 -0700 (PDT) Received: (qmail 2461 invoked from network); 4 Aug 2009 13:49:59 -0000 Received: from unknown (HELO ?192.168.0.10?) (andy@67.125.157.61 with plain) by smtp106.sbc.mail.mud.yahoo.com with SMTP; 4 Aug 2009 13:49:59 -0000 X-YMail-OSG: _hN7VkQVM1ksvy6Zk16ifTwL7cRgr4NgvNQdY8D2V3gf9i98_mcCCyr8KXVoP8BUUZ4nAgsKpZU3jVFnSMvg1mIxUTvPiyRUksBEzaDseCaZmDAd0eGH9PGyG739SdDjEZ5uCrMQk63ETxk9X3FTIBLhLm9jF5YqWZdI1lCrAg8gkQoC_4plUeyhs6N5gTh7QfzbnathkM4b_BT3V95UzhPk35oHHq7HM8nsR8TGYu6B3L1C6Zp2D8JmH6A5.cDWbWsnSL111ELGUCzBTidwpjTg9D6l15u6bLVzJ60mwdutMeU- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4A783CAD.3090301@netconfcentral.com> Date: Tue, 04 Aug 2009 06:50:37 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.22 (X11/20090608) MIME-Version: 1.0 To: WashamFan References: <4A71D2E9.4080004@netconfcentral.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: NETCONF Subject: Re: [Netconf] with-defaults clarification 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, 04 Aug 2009 13:50:08 -0000 WashamFan wrote: > Hi, > > ----- Original Message ----- > From: Andy Bierman > Date: Friday, July 31, 2009 1:07 am > Subject: [Netconf] with-defaults clarification > To: NETCONF > > >> Hi, >> >> I think the with-defaults draft should be clarified to >> indicate that the parameter is ignored >> for if the target of the copy operation >> is the candidate or running databases. > > What does "ignored" herein exactly mean? How to handle default data if > we "ignored" ? > > As discussed in subsequent mails, it is up to operator to decide how > to handle the defaults, so why bother to dictate operator should ignore > or comply with the ? > Note the direction of the copy-config here. This is for data going into the candidate or running config, not data retrieved from it. Ignored means "has no affect". > washam > >> Andy Andy From andy@netconfcentral.com Tue Aug 4 07:37:34 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 A347528C344 for ; Tue, 4 Aug 2009 07:37:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.478 X-Spam-Level: X-Spam-Status: No, score=-2.478 tagged_above=-999 required=5 tests=[AWL=0.121, 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 NswqHiEVWcZt for ; Tue, 4 Aug 2009 07:37:33 -0700 (PDT) Received: from smtp113.sbc.mail.mud.yahoo.com (smtp113.sbc.mail.mud.yahoo.com [68.142.198.212]) by core3.amsl.com (Postfix) with SMTP id C08DD3A703C for ; Tue, 4 Aug 2009 07:37:33 -0700 (PDT) Received: (qmail 8370 invoked from network); 4 Aug 2009 14:36:56 -0000 Received: from unknown (HELO ?192.168.0.10?) (andy@67.125.157.61 with plain) by smtp113.sbc.mail.mud.yahoo.com with SMTP; 4 Aug 2009 14:36:56 -0000 X-YMail-OSG: yHXZVPYVM1lERrv4WpC6oMYIDImaRVdX8l7ILYc6VmWza_zKqhKWrZNkI4AXKQUGzJdT8em01oUElYkl34SQ12RAMJmXqR3exvzdFriDcOB9JXKyhad3OG162Z4QfKIoeif.o_rMstZ9l85_d6nxFAIzV2RwsnlGYOY6YINB1h3RAJEBFMrc4zvwKsHOe2LLp39E02RsckYTikF0J1KwF5XIYxa0l8dSqoCPiT1hUJPDc1NjbqT3RG_EJK6sJw-- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4A784734.7080201@netconfcentral.com> Date: Tue, 04 Aug 2009 07:35:32 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.22 (X11/20090608) MIME-Version: 1.0 To: Andy Bierman , "Bert Wijnen (IETF)" , David B Harrington , Netconf References: <20090803202203.GA20902@elstar.local> <4A7773BB.1080206@netconfcentral.com> <20090804095639.GA21611@elstar.local> In-Reply-To: <20090804095639.GA21611@elstar.local> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [Netconf] Fw: Database Architecture OK or NOT-OK? 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, 04 Aug 2009 14:37:34 -0000 Juergen Schoenwaelder wrote: > On Tue, Aug 04, 2009 at 01:33:15AM +0200, Andy Bierman wrote: > >> IMO, :candidate and :writable-running do not work >> together. They almost work together, and only go horribly wrong >> sometimes. If that's good enough for the NETCONF >> database architecture, then I guess there is nothing to fix. > > The case where a running timed commit interferes with an > edit-config('running', ...) can probably be fixed by letting any > attempts to change running fail while a commit is in > progress. > > Are there other things that can go horribly wrong? > I've already pointed them out at least twice. I'm never going to support this combo, so I don't care anymore. Use locking or get what get. It is interesting that just a lock on candidate will prevent any changes to :writable-running though. The candidate has to stay in synch with running. If the agent cannot copy the new changes to running into candidate because candidate is locked, the agent must not allow running to be edited. Not sure the draft is clear on this point. > /js > Andy From j.schoenwaelder@jacobs-university.de Tue Aug 4 07:49: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 C86C83A706C for ; Tue, 4 Aug 2009 07:49:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.215 X-Spam-Level: X-Spam-Status: No, score=-2.215 tagged_above=-999 required=5 tests=[AWL=0.034, 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 S7FfEbMKEe8i for ; Tue, 4 Aug 2009 07:49:08 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id B64A13A703C for ; Tue, 4 Aug 2009 07:48:38 -0700 (PDT) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 30BDCC0052; Tue, 4 Aug 2009 16:48:41 +0200 (CEST) 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 pKgu6tb+NqKF; Tue, 4 Aug 2009 16:48:40 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 371ACC002B; Tue, 4 Aug 2009 16:48:40 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id E3B7FB788F9; Tue, 4 Aug 2009 16:48:38 +0200 (CEST) Date: Tue, 4 Aug 2009 16:48:38 +0200 From: Juergen Schoenwaelder To: Andy Bierman Message-ID: <20090804144838.GA962@elstar.local> Mail-Followup-To: Andy Bierman , "Bert Wijnen (IETF)" , David B Harrington , Netconf References: <20090803202203.GA20902@elstar.local> <4A7773BB.1080206@netconfcentral.com> <20090804095639.GA21611@elstar.local> <4A784734.7080201@netconfcentral.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4A784734.7080201@netconfcentral.com> User-Agent: Mutt/1.5.19 (2009-01-05) Cc: Netconf Subject: Re: [Netconf] Fw: Database Architecture OK or NOT-OK? 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, 04 Aug 2009 14:49:08 -0000 On Tue, Aug 04, 2009 at 04:35:32PM +0200, Andy Bierman wrote: > It is interesting that just a lock on candidate > will prevent any changes to :writable-running though. > The candidate has to stay in synch with running. Why is this the case? > If the agent cannot copy the new changes to running > into candidate because candidate is locked, > the agent must not allow running to be edited. > Not sure the draft is clear on this point. It is not clear to me why changes to running can't happen while candidate is locked. It is probably not terribly useful but it is unclear why it must be forbidden. Can you explain? /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 Tue Aug 4 08:09: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 8D52728C211 for ; Tue, 4 Aug 2009 08:09:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.481 X-Spam-Level: X-Spam-Status: No, score=-2.481 tagged_above=-999 required=5 tests=[AWL=0.118, 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 2QXuRPqXyGHl for ; Tue, 4 Aug 2009 08:09:51 -0700 (PDT) Received: from smtp111.sbc.mail.mud.yahoo.com (smtp111.sbc.mail.mud.yahoo.com [68.142.198.210]) by core3.amsl.com (Postfix) with SMTP id B65DE28C3E3 for ; Tue, 4 Aug 2009 08:08:41 -0700 (PDT) Received: (qmail 90290 invoked from network); 4 Aug 2009 15:08:20 -0000 Received: from unknown (HELO ?192.168.0.10?) (andy@67.125.157.61 with plain) by smtp111.sbc.mail.mud.yahoo.com with SMTP; 4 Aug 2009 15:08:20 -0000 X-YMail-OSG: aOgQYSgVM1kAlr__vhNV3LWHShEvTIJ6PUmdW3DAuPI3OuLwjbSx5TCrWhQ5iXtm7p1iu8AB_vq9sUyjhFelMp7jJYRAfKCRxJpBqwnM2NweFuoINcvNQ1ih4s4fZQVn8RZFPmVi9.NBFyKQpBDCCpJGxn1Kpz.mU.BJd.iVekN1zOJavMBn3Vl6q1wElHBl8b7yHWIDO_qfcGqCPmHl1s7yfNLk_4bj.ARDD1.nzoqiAAIMooSKBj6TQAlbyQ-- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4A784E8E.8000007@netconfcentral.com> Date: Tue, 04 Aug 2009 08:06:54 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.22 (X11/20090608) MIME-Version: 1.0 To: Andy Bierman , "Bert Wijnen (IETF)" , David B Harrington , Netconf References: <20090803202203.GA20902@elstar.local> <4A7773BB.1080206@netconfcentral.com> <20090804095639.GA21611@elstar.local> <4A784734.7080201@netconfcentral.com> <20090804144838.GA962@elstar.local> In-Reply-To: <20090804144838.GA962@elstar.local> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [Netconf] Fw: Database Architecture OK or NOT-OK? 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, 04 Aug 2009 15:09:52 -0000 Juergen Schoenwaelder wrote: > On Tue, Aug 04, 2009 at 04:35:32PM +0200, Andy Bierman wrote: > >> It is interesting that just a lock on candidate >> will prevent any changes to :writable-running though. >> The candidate has to stay in synch with running. > > Why is this the case? > if it does not, then when a commit is done, the recent changes to running will be lost because they are not in the candidate. The agent will interpret the missing node in candidate as a deletion in running. >> If the agent cannot copy the new changes to running >> into candidate because candidate is locked, >> the agent must not allow running to be edited. >> Not sure the draft is clear on this point. > > It is not clear to me why changes to running can't happen while > candidate is locked. It is probably not terribly useful but it is > unclear why it must be forbidden. Can you explain? > Fine. It should be allowed. The changes will be undone by a commit, but garbage-in/garbage-out happens sometimes, and this is one of them. Also, the draft never specifies the initial contents of the candidate (IMO, sloppy). > /js > Andy From j.schoenwaelder@jacobs-university.de Tue Aug 4 11:41: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 5543C3A6A72 for ; Tue, 4 Aug 2009 11:41:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.216 X-Spam-Level: X-Spam-Status: No, score=-2.216 tagged_above=-999 required=5 tests=[AWL=0.033, 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 dZK-EWfc5QRw for ; Tue, 4 Aug 2009 11:41:39 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 1849F3A68FF for ; Tue, 4 Aug 2009 11:41:38 -0700 (PDT) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 91FB4C0056; Tue, 4 Aug 2009 20:41:39 +0200 (CEST) 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 rSbEZGAaO5jB; Tue, 4 Aug 2009 20:41:38 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 65DE6C0055; Tue, 4 Aug 2009 20:41:38 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id E367DB78BB2; Tue, 4 Aug 2009 20:41:36 +0200 (CEST) Date: Tue, 4 Aug 2009 20:41:36 +0200 From: Juergen Schoenwaelder To: Andy Bierman Message-ID: <20090804184136.GC1038@elstar.local> Mail-Followup-To: Andy Bierman , "Bert Wijnen (IETF)" , David B Harrington , Netconf References: <20090803202203.GA20902@elstar.local> <4A7773BB.1080206@netconfcentral.com> <20090804095639.GA21611@elstar.local> <4A784734.7080201@netconfcentral.com> <20090804144838.GA962@elstar.local> <4A784E8E.8000007@netconfcentral.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4A784E8E.8000007@netconfcentral.com> User-Agent: Mutt/1.5.19 (2009-01-05) Cc: Netconf Subject: Re: [Netconf] Fw: Database Architecture OK or NOT-OK? 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, 04 Aug 2009 18:41:41 -0000 On Tue, Aug 04, 2009 at 05:06:54PM +0200, Andy Bierman wrote: > Juergen Schoenwaelder wrote: > > On Tue, Aug 04, 2009 at 04:35:32PM +0200, Andy Bierman wrote: > > > >> It is interesting that just a lock on candidate > >> will prevent any changes to :writable-running though. > >> The candidate has to stay in synch with running. > > > > Why is this the case? > > if it does not, then when a commit is done, > the recent changes to running will be lost > because they are not in the candidate. > The agent will interpret the missing node in > candidate as a deletion in running. I am fine accepting this behaviour. What I find more interesting is the question whether a well behaved manager can try to avoid this situation, e.g. by locking running and candidate. Can I commit() the candidate while I own the lock for running? That is, can I do this: lock('running') discard-changes() lock('candidate') edit-config('candidate', ...) commit() unlock('candidate') unlock('running') I still find it surprising that I have to do the discard-changes() before lock('candidate') but Phil strongly believes that failing lock('candidate') if 'candidate' != 'running' is the correct way of doing things. > Also, the draft never specifies the initial contents of the > candidate (IMO, sloppy). Can you suggest words that should be there? I would probably issue a discard-changes() whenever I want to use 'candidate' so I can be sure what its contents is. And since discard-changes() and lock('candidate') are not atomic, the real code likely becomes this: lock('running') do { discard-changes() lock('candidate') } until lock-aquired edit-config('candidate', ...) commit() unlock('candidate') unlock('running') But I already wrote a about this... /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From bertietf@bwijnen.net Tue Aug 4 12:22: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 3FFAC3A6844 for ; Tue, 4 Aug 2009 12:22:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.316 X-Spam-Level: X-Spam-Status: No, score=-8.316 tagged_above=-999 required=5 tests=[AWL=2.283, 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 e1V-puYqKtsg for ; Tue, 4 Aug 2009 12:22:24 -0700 (PDT) Received: from postgirl.ripe.net (postgirl.ripe.net [193.0.19.66]) by core3.amsl.com (Postfix) with ESMTP id 7930A3A6940 for ; Tue, 4 Aug 2009 12:22:22 -0700 (PDT) Received: from herring.ripe.net ([193.0.1.203]) by postgirl.ripe.net with esmtp (Exim 4.63) (envelope-from ) id 1MYPaQ-0002kG-MK; Tue, 04 Aug 2009 21:22:20 +0200 Received: from BWMACBOOK.local (dog.ripe.net [193.0.1.217]) by herring.ripe.net (Postfix) with ESMTP id 8C46D2F595; Tue, 4 Aug 2009 21:22:14 +0200 (CEST) Message-ID: <4A788A66.4030106@bwijnen.net> Date: Tue, 04 Aug 2009 21:22:14 +0200 From: "Bert (IETF) Wijnen" User-Agent: Thunderbird 2.0.0.22 (Macintosh/20090605) MIME-Version: 1.0 To: Juergen Schoenwaelder , Netconf References: <20090803202203.GA20902@elstar.local> <4A7773BB.1080206@netconfcentral.com> <20090804095639.GA21611@elstar.local> <4A784734.7080201@netconfcentral.com> <20090804144838.GA962@elstar.local> <4A784E8E.8000007@netconfcentral.com> <20090804184136.GC1038@elstar.local> In-Reply-To: <20090804184136.GC1038@elstar.local> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-RIPE-Spam-Level: ---- X-RIPE-Signature: 86ab03e524994f79ca2c75a176445dd40f6bd5f08879bac77e238e20fc070333 Subject: Re: [Netconf] Fw: Database Architecture OK or NOT-OK? 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, 04 Aug 2009 19:22:25 -0000 Juergen Schoenwaelder wrote: > > I would probably issue a discard-changes() whenever I want to use > 'candidate' so I can be sure what its contents is. And since > discard-changes() and lock('candidate') are not atomic, the real code > likely becomes this: > > lock('running') > do { > discard-changes() > lock('candidate') > } until lock-aquired > edit-config('candidate', ...) > commit() > unlock('candidate') > unlock('running') > > would you not rather first get the lock on candidate before you do a discard-changes ?? otherwise someone else might still change the candidate in between your discard-changes and lock, no? Bert From j.schoenwaelder@jacobs-university.de Tue Aug 4 14:14: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 D68A83A70C8 for ; Tue, 4 Aug 2009 14:14:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.21 X-Spam-Level: X-Spam-Status: No, score=-2.21 tagged_above=-999 required=5 tests=[AWL=0.039, 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 vNwqynbHCOhm for ; Tue, 4 Aug 2009 14:14:50 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id B67BE3A70C7 for ; Tue, 4 Aug 2009 14:14:49 -0700 (PDT) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id 3DD4AC0055; Tue, 4 Aug 2009 23:14:52 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius1.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id lzwg4CoSFwIl; Tue, 4 Aug 2009 23:14:51 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 2B413C0054; Tue, 4 Aug 2009 23:14:51 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 0481DB78E40; Tue, 4 Aug 2009 23:14:49 +0200 (CEST) Date: Tue, 4 Aug 2009 23:14:49 +0200 From: Juergen Schoenwaelder To: "Bert (IETF) Wijnen" Message-ID: <20090804211449.GA1307@elstar.local> Mail-Followup-To: "Bert (IETF) Wijnen" , Netconf References: <20090803202203.GA20902@elstar.local> <4A7773BB.1080206@netconfcentral.com> <20090804095639.GA21611@elstar.local> <4A784734.7080201@netconfcentral.com> <20090804144838.GA962@elstar.local> <4A784E8E.8000007@netconfcentral.com> <20090804184136.GC1038@elstar.local> <4A788A66.4030106@bwijnen.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4A788A66.4030106@bwijnen.net> User-Agent: Mutt/1.5.19 (2009-01-05) Cc: Netconf Subject: Re: [Netconf] Fw: Database Architecture OK or NOT-OK? 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, 04 Aug 2009 21:14:50 -0000 On Tue, Aug 04, 2009 at 09:22:14PM +0200, Bert (IETF) Wijnen wrote: > Juergen Schoenwaelder wrote: > > > > I would probably issue a discard-changes() whenever I want to use > > 'candidate' so I can be sure what its contents is. And since > > discard-changes() and lock('candidate') are not atomic, the real code > > likely becomes this: > > > > lock('running') > > do { > > discard-changes() > > lock('candidate') > > } until lock-aquired > > edit-config('candidate', ...) > > commit() > > unlock('candidate') > > unlock('running') > > > > > > would you not rather first get the lock on candidate before you do a > discard-changes ?? > otherwise someone else might still change the candidate in between your > discard-changes and lock, no? The NETCONF RFC says that lock('candidate') fails if 'candidate' is dirty. So you have to clean 'candidate' before you can get the lock and since discarding changes and locking is not atomic, you get a loop like above. Also note that unlock('candidate') reverts candidate back to 'running' - but I have less an issue with that (although I probably would not have designed things this way myself). /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 Tue Aug 4 14:23: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 E5A7B3A70D4 for ; Tue, 4 Aug 2009 14:23:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.484 X-Spam-Level: X-Spam-Status: No, score=-2.484 tagged_above=-999 required=5 tests=[AWL=0.115, 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 cnerJ0MwlIhM for ; Tue, 4 Aug 2009 14:23:18 -0700 (PDT) Received: from smtp109.sbc.mail.mud.yahoo.com (smtp109.sbc.mail.mud.yahoo.com [68.142.198.208]) by core3.amsl.com (Postfix) with SMTP id 29AC43A69D5 for ; Tue, 4 Aug 2009 14:23:18 -0700 (PDT) Received: (qmail 69798 invoked from network); 4 Aug 2009 21:23:19 -0000 Received: from unknown (HELO ?192.168.0.10?) (andy@67.125.157.61 with plain) by smtp109.sbc.mail.mud.yahoo.com with SMTP; 4 Aug 2009 21:23:18 -0000 X-YMail-OSG: uIqIZMkVM1mMgnYGvgyA0Ks72xdTlg3EnOtj5yACiMdpXvv0HsB.tvam.D3sQc6F7OOFZ3NEf6gltH.A_35wVnGuERTvrzRa250YR4gl_OcUQm8j4f5vnWRoZhuOY1drDa_dH63Eg4iszWGgneRtPMZK98s87.L5RBUARKdXm_RDLFNp4ew9ZFdzvjiDRaKQavyMfmll0VXgXMpNUuOMBlypDa8a0w56LTG46JDIv8bGf4xQtuYmB5mUcOWkT_5IUhPXRkpQeYjYsbY- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4A78A676.3010308@netconfcentral.com> Date: Tue, 04 Aug 2009 14:21:58 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.22 (X11/20090608) MIME-Version: 1.0 To: "Bert (IETF) Wijnen" , Netconf References: <20090803202203.GA20902@elstar.local> <4A7773BB.1080206@netconfcentral.com> <20090804095639.GA21611@elstar.local> <4A784734.7080201@netconfcentral.com> <20090804144838.GA962@elstar.local> <4A784E8E.8000007@netconfcentral.com> <20090804184136.GC1038@elstar.local> <4A788A66.4030106@bwijnen.net> <20090804211449.GA1307@elstar.local> In-Reply-To: <20090804211449.GA1307@elstar.local> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [Netconf] Fw: Database Architecture OK or NOT-OK? 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, 04 Aug 2009 21:23:19 -0000 Juergen Schoenwaelder wrote: > On Tue, Aug 04, 2009 at 09:22:14PM +0200, Bert (IETF) Wijnen wrote: >> Juergen Schoenwaelder wrote: >>> I would probably issue a discard-changes() whenever I want to use >>> 'candidate' so I can be sure what its contents is. And since >>> discard-changes() and lock('candidate') are not atomic, the real code >>> likely becomes this: >>> >>> lock('running') >>> do { >>> discard-changes() >>> lock('candidate') >>> } until lock-aquired >>> edit-config('candidate', ...) >>> commit() >>> unlock('candidate') >>> unlock('running') >>> >>> >> would you not rather first get the lock on candidate before you do a >> discard-changes ?? >> otherwise someone else might still change the candidate in between your >> discard-changes and lock, no? > > The NETCONF RFC says that lock('candidate') fails if 'candidate' is > dirty. So you have to clean 'candidate' before you can get the lock > and since discarding changes and locking is not atomic, you get a loop > like above. > > Also note that unlock('candidate') reverts candidate back to 'running' > - but I have less an issue with that (although I probably would not > have designed things this way myself). > Not in my code. I don't see that anywhere in sec. 7.6. Losing the lock via session termination doesn't even revert the candidate. This is 1 reason why the candidate may be dirty in the first place. > /js > Andy From andy@netconfcentral.com Tue Aug 4 14:36: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 2DFAE3A6E8C for ; Tue, 4 Aug 2009 14:36:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.487 X-Spam-Level: X-Spam-Status: No, score=-2.487 tagged_above=-999 required=5 tests=[AWL=0.112, 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 iELOrueF1o+J for ; Tue, 4 Aug 2009 14:36:56 -0700 (PDT) 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 737903A6A43 for ; Tue, 4 Aug 2009 14:36:56 -0700 (PDT) Received: (qmail 8504 invoked from network); 4 Aug 2009 21:36:59 -0000 Received: from unknown (HELO ?192.168.0.10?) (andy@67.125.157.61 with plain) by smtp103.sbc.mail.mud.yahoo.com with SMTP; 4 Aug 2009 21:36:59 -0000 X-YMail-OSG: 2R4nlM4VM1ksrQrffX0o0LrTTiPPWzMzKIbOrjocnrWPNYlYHuyJVwA_H91rB3kV9V8olU6a4_EiUUyPVcPZHK5DgdSCSAbCPL4Y6d3GR3ydTZ0pbVNo608RB98qTzVHTnC5MWo9x.iMCnJAYmpNbbmzMPeRGdwzuxja1q2YxMBFXDF6S2f572m8dED1KhhlECK2KwVk_mQ92vJD0_xE74kXB8tjCb7nBTDCFY90758kyyscg5EsTpQmSwAX_h7HZfnLhep92Zd8O8JEwNBclNxN7WcYmJHywxUmcGk0ViajEuoh_2o- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4A78AA22.4070405@netconfcentral.com> Date: Tue, 04 Aug 2009 14:37:38 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.22 (X11/20090608) MIME-Version: 1.0 To: "Bert (IETF) Wijnen" , Netconf References: <20090803202203.GA20902@elstar.local> <4A7773BB.1080206@netconfcentral.com> <20090804095639.GA21611@elstar.local> <4A784734.7080201@netconfcentral.com> <20090804144838.GA962@elstar.local> <4A784E8E.8000007@netconfcentral.com> <20090804184136.GC1038@elstar.local> <4A788A66.4030106@bwijnen.net> <20090804211449.GA1307@elstar.local> In-Reply-To: <20090804211449.GA1307@elstar.local> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [Netconf] Fw: Database Architecture OK or NOT-OK? 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, 04 Aug 2009 21:36:57 -0000 Juergen Schoenwaelder wrote: .... > The NETCONF RFC says that lock('candidate') fails if 'candidate' is > dirty. So you have to clean 'candidate' before you can get the lock > and since discarding changes and locking is not atomic, you get a loop > like above. > Note that the agent MUST send the session-id of the lock-holder (lock-denied error-tag), but in this case, there is no lock holder. Is the agent supposed to send session-id=0 in this case? That will look like SNMP or CLI has the lock. It is possible an operator may not have read the 1 sentence buried in a 120 page document that explains why this is happening, and have no idea that is the only thing that will fix it. (I agree with you about using copy-config instead of discard-changes. I never bought the argument that the candidate was so special it needed its own set of operations.) > > /js > Andy From andy@netconfcentral.com Tue Aug 4 14:44: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 6FCFD3A6992 for ; Tue, 4 Aug 2009 14:44:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.49 X-Spam-Level: X-Spam-Status: No, score=-2.49 tagged_above=-999 required=5 tests=[AWL=0.109, 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 IEX0o7RzPfjI for ; Tue, 4 Aug 2009 14:44:51 -0700 (PDT) Received: from smtp113.sbc.mail.mud.yahoo.com (smtp113.sbc.mail.mud.yahoo.com [68.142.198.212]) by core3.amsl.com (Postfix) with SMTP id 46B0A28C244 for ; Tue, 4 Aug 2009 14:44:27 -0700 (PDT) Received: (qmail 37924 invoked from network); 4 Aug 2009 21:44:28 -0000 Received: from unknown (HELO ?192.168.0.10?) (andy@67.125.157.61 with plain) by smtp113.sbc.mail.mud.yahoo.com with SMTP; 4 Aug 2009 21:44:28 -0000 X-YMail-OSG: wzrHls8VM1nj9fADy5mEwxJpVx6sBiK.pbdAkhcc8KPEf4yn8p9ieZjSLyv56xAz64wXArZBoPjWh1woCf0D33bR_2s7mH9UaDC5pjGe2GUOtcfQmTaRCU8vIO1UZDv6I4zOzXuyP71OF1vVvOZP0Lrz88_FwGI6iKtsW0gG_yjBxoq6.LvFGV1KPv5o3XFkdxW9HqnO1u0OzwORQITHkdHJNBlcdB9hCeWDnxe3paKhR.yrep1RwtgzCK5OZMW271IzyMs2hrx4PWrqH_u_Ylvv87ozPqiVgci.v8vtbPPoMpE0778- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4A78ABE4.4010403@netconfcentral.com> Date: Tue, 04 Aug 2009 14:45:08 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.22 (X11/20090608) MIME-Version: 1.0 To: "Bert (IETF) Wijnen" , Netconf References: <20090803202203.GA20902@elstar.local> <4A7773BB.1080206@netconfcentral.com> <20090804095639.GA21611@elstar.local> <4A784734.7080201@netconfcentral.com> <20090804144838.GA962@elstar.local> <4A784E8E.8000007@netconfcentral.com> <20090804184136.GC1038@elstar.local> <4A788A66.4030106@bwijnen.net> <20090804211449.GA1307@elstar.local> In-Reply-To: <20090804211449.GA1307@elstar.local> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [Netconf] Fw: Database Architecture OK or NOT-OK? 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, 04 Aug 2009 21:44:52 -0000 Juergen Schoenwaelder wrote: ... > The NETCONF RFC says that lock('candidate') fails if 'candidate' is > dirty. So you have to clean 'candidate' before you can get the lock > and since discarding changes and locking is not atomic, you get a loop > like above. > > Can we change this in 4741bis? Why is the candidate so special? I don't get it at all. If the user doesn't use locking, then too bad, so sad. Somebody else can just discard your changes without any lock, so what is the point of preventing a lock once you have touched the candidate somehow? The loop should go away. The lock should succeed on candidate, unless it is currently locked. Then the discard-changes command could go after the lock was granted, and there would be no confusion wrt/ lock-denied yet no session is holding the lock. > /js > Andy From Washam.Fan@huaweisymantec.com Tue Aug 4 19:23: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 A7CDA3A6F9C for ; Tue, 4 Aug 2009 19:23:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.406 X-Spam-Level: X-Spam-Status: No, score=-0.406 tagged_above=-999 required=5 tests=[AWL=0.089, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RXHShOhYVgWL for ; Tue, 4 Aug 2009 19:23:06 -0700 (PDT) Received: from mta2.huaweisymantec.com (unknown [218.17.155.15]) by core3.amsl.com (Postfix) with ESMTP id D9D213A6887 for ; Tue, 4 Aug 2009 19:23:05 -0700 (PDT) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-disposition: inline Content-type: text/plain; charset=us-ascii Received: from hstml01-in.huaweisymantec.com ([172.26.3.42]) by hstga02-in.huaweisymantec.com (Sun Java(tm) System Messaging Server 6.3-8.03 (built Apr 24 2009; 32bit)) with ESMTP id <0KNV00LK4TAABE40@hstga02-in.huaweisymantec.com> for netconf@ietf.org; Wed, 05 Aug 2009 10:22:58 +0800 (CST) Received: from huaweisymantec.com ([127.0.0.1]) by hstml01-in.huaweisymantec.com (Sun Java(tm) System Messaging Server 6.3-8.03 (built Apr 24 2009; 32bit)) with ESMTP id <0KNV009SZTAAY200@hstml01-in.huaweisymantec.com> for netconf@ietf.org; Wed, 05 Aug 2009 10:22:58 +0800 (CST) Received: from [10.27.154.141] by hstml01-in.huaweisymantec.com (mshttpd); Wed, 05 Aug 2009 10:22:58 +0800 From: WashamFan To: Andy Bierman Message-id: Date: Wed, 05 Aug 2009 10:22:58 +0800 X-Mailer: Sun Java(tm) System Messenger Express 6.3-8.03 (built Apr 24 2009; 32bit) Content-language: en X-Accept-Language: en Priority: normal In-reply-to: <4A783CAD.3090301@netconfcentral.com> References: <4A71D2E9.4080004@netconfcentral.com> <4A783CAD.3090301@netconfcentral.com> Cc: NETCONF Subject: Re: [Netconf] with-defaults clarification 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, 05 Aug 2009 02:23:06 -0000 Hi, > >> Hi, > >> > >> I think the with-defaults draft should be clarified to > >> indicate that the parameter is ignored > >> for if the target of the copy operation > >> is the candidate or running databases. > > > > What does "ignored" herein exactly mean? How to handle default data > if > > we "ignored" ? > > > > As discussed in subsequent mails, it is up to operator to decide how > > to handle the defaults, so why bother to dictate operator should ignore > > or comply with the ? > > > > Note the direction of the copy-config here. > This is for data going into the candidate or running config, > not data retrieved from it. > > Ignored means "has no affect". The agent should handle default data regardless of ignoring or not. Are you saying "ignored" means agent can handle default data at its will? (I.e., agent might trim defaults, might report all defaults, which depends on intrinsic implementation) washam From andy@netconfcentral.com Tue Aug 4 20:15: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 145BC3A7149 for ; Tue, 4 Aug 2009 20:15:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.493 X-Spam-Level: X-Spam-Status: No, score=-2.493 tagged_above=-999 required=5 tests=[AWL=0.106, 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 G2Nu8uk6wAZ3 for ; Tue, 4 Aug 2009 20:15:55 -0700 (PDT) Received: from n9.bullet.mail.mud.yahoo.com (n9.bullet.mail.mud.yahoo.com [209.191.86.157]) by core3.amsl.com (Postfix) with SMTP id 01D713A7144 for ; Tue, 4 Aug 2009 20:15:54 -0700 (PDT) Received: from [68.142.200.224] by n9.bullet.mail.mud.yahoo.com with NNFMP; 05 Aug 2009 03:15:55 -0000 Received: from [68.142.201.250] by t5.bullet.mud.yahoo.com with NNFMP; 05 Aug 2009 03:15:55 -0000 Received: from [127.0.0.1] by omp411.mail.mud.yahoo.com with NNFMP; 05 Aug 2009 03:15:55 -0000 X-Yahoo-Newman-Id: 802985.94279.bm@omp411.mail.mud.yahoo.com Received: (qmail 30115 invoked from network); 5 Aug 2009 03:15:55 -0000 Received: from unknown (HELO ?192.168.0.10?) (andy@67.125.157.61 with plain) by smtp105.sbc.mail.sp1.yahoo.com with SMTP; 5 Aug 2009 03:15:55 -0000 X-YMail-OSG: P8R9xboVM1naGIdmRF9kLp2o455W7TmRONiwHu1h8u5EwtY.un.Wht7sbzT5oJ7FyMGFrtDdjjKPSkyxnRCBZPQKGH.SdaJlK.J5uPqLWX2IaxndOrm7m0721UJFPEP_lIG0IOEcrl4JBdRdxlmjvoXodC5NLN25MWpYh77j9vjPxJqbsUjbFtaeySwoXiwnnEZb7fGsz5yXCnEmsW4IlqO3IVXqRu0AhR5A0uM1_ngcKiDqcp8rYRem2KdAyxi0EY7XtyV0u.2CHjlZ9m9IjMhhseQZzrh1ceMQ3qZvlsAzaBvSqmc- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4A78F919.2050303@netconfcentral.com> Date: Tue, 04 Aug 2009 20:14:33 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.22 (X11/20090608) MIME-Version: 1.0 To: WashamFan References: <4A71D2E9.4080004@netconfcentral.com> <4A783CAD.3090301@netconfcentral.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: NETCONF Subject: Re: [Netconf] with-defaults clarification 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, 05 Aug 2009 03:15:56 -0000 WashamFan wrote: > Hi, > >> >> Hi, >> >> >> >> I think the with-defaults draft should be clarified to >> >> indicate that the parameter is ignored >> >> for if the target of the copy operation >> >> is the candidate or running databases. >> > >> > What does "ignored" herein exactly mean? How to handle default data >> if >> > we "ignored" ? >> > >> > As discussed in subsequent mails, it is up to operator to decide how >> > to handle the defaults, so why bother to dictate operator should ignore >> > or comply with the ? >> > >> >> Note the direction of the copy-config here. >> This is for data going into the candidate or running config, >> not data retrieved from it. >> >> Ignored means "has no affect". > > The agent should handle default data regardless of ignoring or not. > Are you saying "ignored" means agent can handle default data at its will? > (I.e., agent might trim defaults, might report all defaults, which depends > on intrinsic implementation) > The agent will use its internal defaults handling scheme when filling the candidate or running databases via copy-config. The with-defaults parameter is a filter for retrieval purposes. When transferring data INTO a database, the agent is allowed to populate the database with or without default leafs. This is part of the YANG spec, and with-defaults needs to be consistent with YANG rules. > washam > > Andy From Washam.Fan@huaweisymantec.com Tue Aug 4 21:41: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 6EC9E3A7153 for ; Tue, 4 Aug 2009 21:41:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.417 X-Spam-Level: X-Spam-Status: No, score=-0.417 tagged_above=-999 required=5 tests=[AWL=0.078, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wnf7566rc2GG for ; Tue, 4 Aug 2009 21:41:32 -0700 (PDT) Received: from mta1.huaweisymantec.com (unknown [218.17.155.14]) by core3.amsl.com (Postfix) with ESMTP id 561CA3A7157 for ; Tue, 4 Aug 2009 21:41:30 -0700 (PDT) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-disposition: inline Content-type: text/plain; charset=us-ascii Received: from hstml01-in.huaweisymantec.com ([172.26.3.41]) by hstga01-in.huaweisymantec.com (Sun Java(tm) System Messaging Server 6.3-8.03 (built Apr 24 2009; 32bit)) with ESMTP id <0KNV00JXJZOYQZ90@hstga01-in.huaweisymantec.com> for netconf@ietf.org; Wed, 05 Aug 2009 12:41:22 +0800 (CST) Received: from huaweisymantec.com ([127.0.0.1]) by hstml01-in.huaweisymantec.com (Sun Java(tm) System Messaging Server 6.3-8.03 (built Apr 24 2009; 32bit)) with ESMTP id <0KNV0084BZOYQF10@hstml01-in.huaweisymantec.com> for netconf@ietf.org; Wed, 05 Aug 2009 12:41:22 +0800 (CST) Received: from [10.27.154.141] by hstml01-in.huaweisymantec.com (mshttpd); Wed, 05 Aug 2009 12:41:22 +0800 From: WashamFan To: Andy Bierman Message-id: Date: Wed, 05 Aug 2009 12:41:22 +0800 X-Mailer: Sun Java(tm) System Messenger Express 6.3-8.03 (built Apr 24 2009; 32bit) Content-language: en X-Accept-Language: en Priority: normal In-reply-to: <4A78F919.2050303@netconfcentral.com> References: <4A71D2E9.4080004@netconfcentral.com> <4A783CAD.3090301@netconfcentral.com> <4A78F919.2050303@netconfcentral.com> Cc: NETCONF Subject: Re: [Netconf] with-defaults clarification 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, 05 Aug 2009 04:41:36 -0000 Hi, > > The agent will use its internal defaults handling scheme > when filling the candidate or running databases via copy-config. > > The with-defaults parameter is a filter for retrieval purposes. > When transferring data INTO a database, the agent is allowed > to populate the database with or without default leafs. > This is part of the YANG spec, and with-defaults needs to be > consistent with YANG rules. Thanks. Could you point out which part of YANG spec dealing with this? washam From Washam.Fan@huaweisymantec.com Tue Aug 4 23:10: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 1823528C4AA for ; Tue, 4 Aug 2009 23:10:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.426 X-Spam-Level: X-Spam-Status: No, score=-0.426 tagged_above=-999 required=5 tests=[AWL=0.069, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Et88r7nbrywm for ; Tue, 4 Aug 2009 23:10:05 -0700 (PDT) Received: from mta1.huaweisymantec.com (unknown [218.17.155.14]) by core3.amsl.com (Postfix) with ESMTP id 65B103A684D for ; Tue, 4 Aug 2009 23:08:42 -0700 (PDT) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-disposition: inline Content-type: text/plain; charset=us-ascii Received: from hstml01-in.huaweisymantec.com ([172.26.3.41]) by hstga01-in.huaweisymantec.com (Sun Java(tm) System Messaging Server 6.3-8.03 (built Apr 24 2009; 32bit)) with ESMTP id <0KNW00ISW3QATN00@hstga01-in.huaweisymantec.com> for netconf@ietf.org; Wed, 05 Aug 2009 14:08:34 +0800 (CST) Received: from huaweisymantec.com ([127.0.0.1]) by hstml01-in.huaweisymantec.com (Sun Java(tm) System Messaging Server 6.3-8.03 (built Apr 24 2009; 32bit)) with ESMTP id <0KNW008A53QAQF10@hstml01-in.huaweisymantec.com> for netconf@ietf.org; Wed, 05 Aug 2009 14:08:34 +0800 (CST) Received: from [10.27.154.141] by hstml01-in.huaweisymantec.com (mshttpd); Wed, 05 Aug 2009 14:08:34 +0800 From: WashamFan To: Andy Bierman Message-id: Date: Wed, 05 Aug 2009 14:08:34 +0800 X-Mailer: Sun Java(tm) System Messenger Express 6.3-8.03 (built Apr 24 2009; 32bit) Content-language: en X-Accept-Language: en Priority: normal In-reply-to: <4A760385.7050708@netconfcentral.com> References: <4A7473F3.5080709@netconfcentral.com> <25F318D5AD464AAB9D884EA06D23FAFC@BertLaptop> <4A760385.7050708@netconfcentral.com> Cc: NETCONF Subject: Re: [Netconf] partial locking for candidate and startup? 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, 05 Aug 2009 06:10:06 -0000 HI, > Bert Wijnen (IETF) wrote: > > I anm not sure if we made that decision explicitly. > > But I do know that we as a result of discussions/concerns/issues, > we came to > > this text (as currently in revision 09, which is in IESG review): > > > > 2.1.1. Usage Scenarios > > > > In the following we describe a few scenarios for partial locking. > > Partial locking is primarily useful towards the running > > configuration. However it can be used to lock parts of a candidate > > datastore as well. While scenarios using the running datastore > are > > seen as the most important, as an example a scenario involving the > > candidate datastore is also presented. Besides the three described > > here, there are many other usage scenarios possible. > > > > The use case in 2.1.1.3 is a mystery to me. > > I don't really see the point of locking my little > section of the candidate scratchpad, then manually coordinating > with all the other users (by email or SMS?) > "is it OK to do a commit now?". How to do coordination is not clear in current text, but might be clear in some body's mind. > If even one user doesn't get the memo, > and writes to the candidate ignoring all locks, > then the edit-config might succeed. > This can taint the commit -- either it will > fail, or maybe a hacker will get somebody > else to issue for some injected data under some other > user's credentials. partial locking does not introduce this kind of vulnerability. it exists when no locking used. > Partial locking does not work for candidate. > partial locking on candidate MIGHT work for somebody. washam From Washam.Fan@huaweisymantec.com Wed Aug 5 01:05: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 F1BEB3A6F0A for ; Wed, 5 Aug 2009 01:05:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.497 X-Spam-Level: X-Spam-Status: No, score=0.497 tagged_above=-999 required=5 tests=[AWL=-0.867, BAYES_20=-0.74, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SYiQABvLG2Xr for ; Wed, 5 Aug 2009 01:05:05 -0700 (PDT) Received: from mta2.huaweisymantec.com (unknown [218.17.155.15]) by core3.amsl.com (Postfix) with ESMTP id 24ECF28C525 for ; Wed, 5 Aug 2009 01:04:04 -0700 (PDT) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-disposition: inline Content-type: text/plain; charset=us-ascii Received: from hstml01-in.huaweisymantec.com ([172.26.3.42]) by hstga02-in.huaweisymantec.com (Sun Java(tm) System Messaging Server 6.3-8.03 (built Apr 24 2009; 32bit)) with ESMTP id <0KNW00LAY92BBE80@hstga02-in.huaweisymantec.com> for netconf@ietf.org; Wed, 05 Aug 2009 16:03:48 +0800 (CST) Received: from huaweisymantec.com ([127.0.0.1]) by hstml01-in.huaweisymantec.com (Sun Java(tm) System Messaging Server 6.3-8.03 (built Apr 24 2009; 32bit)) with ESMTP id <0KNW009J692BTG10@hstml01-in.huaweisymantec.com> for netconf@ietf.org; Wed, 05 Aug 2009 16:03:47 +0800 (CST) Received: from [10.27.154.141] by hstml01-in.huaweisymantec.com (mshttpd); Wed, 05 Aug 2009 16:03:47 +0800 From: WashamFan To: Juergen Schoenwaelder Message-id: Date: Wed, 05 Aug 2009 16:03:47 +0800 X-Mailer: Sun Java(tm) System Messenger Express 6.3-8.03 (built Apr 24 2009; 32bit) Content-language: en X-Accept-Language: en Priority: normal In-reply-to: <20090804124420.GA534@elstar.local> References: <20090803202203.GA20902@elstar.local> <4A7773BB.1080206@netconfcentral.com> <20090804095639.GA21611@elstar.local> <20090804114526.GB21708@elstar.local> <20090804124420.GA534@elstar.local> Cc: Netconf Subject: Re: [Netconf] Fw: Database Architecture OK or NOT-OK? 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, 05 Aug 2009 08:05:06 -0000 Hi, > > That depends on how you see the changes between commits. If you > > consider these changes as an additional part of previous undone changes, > > then they can be rollbacked. > > Not sure I understand your point. > > My model is that the start of a commit() defines the running > configuration you roll back to if the commit fails. If this model is > right, then any further changes to the running configuration after the > start of the commit() will be lost - either because the commit > succeeds or there is a rollback. Sorry, I misunderstood. I thought the changes via candidate, but you meant the changes via running. That is different. washam From andy@netconfcentral.com Wed Aug 5 01:14: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 3DF463A68A3 for ; Wed, 5 Aug 2009 01:14:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.328 X-Spam-Level: X-Spam-Status: No, score=-2.328 tagged_above=-999 required=5 tests=[AWL=-0.063, 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 cWc2aKQJECLU for ; Wed, 5 Aug 2009 01:14:55 -0700 (PDT) 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 5E3FC3A718D for ; Wed, 5 Aug 2009 01:14:19 -0700 (PDT) Received: (qmail 375 invoked from network); 5 Aug 2009 08:14:19 -0000 Received: from unknown (HELO ?192.168.0.10?) (andy@67.125.157.61 with plain) by smtp125.sbc.mail.sp1.yahoo.com with SMTP; 5 Aug 2009 08:14:18 -0000 X-YMail-OSG: 7o2Pve0VM1l5Sr8tLzUEVapJbevn_n2duURE_hwezcNqDiZ6d5ZyGZfyv9dZ5PobStgUpgQ5Fu9DmR7lLyw6ZbDba_rPfCm78kGGULQc_S7tCKEWWN2janT6BLz1wIqNVj4e0qWIxzynDCMChrobovC_aShq4aSXRpcA0UBseRH8jsOH.6sKGs1hd8LhkSS8AXuUl8_Wf.iURwNS1wo1_YLTLQ1zOnPza1NR2S5DlkeLut5csksshYmhJ9TcEyf0SR9LZgWer8iwU2d5qQX37xPpZ.fwP1f9AfQmtRHZEyvDewB7NBA- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4A793F85.4040801@netconfcentral.com> Date: Wed, 05 Aug 2009 01:15:01 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.22 (X11/20090608) MIME-Version: 1.0 To: WashamFan References: <4A71D2E9.4080004@netconfcentral.com> <4A783CAD.3090301@netconfcentral.com> <4A78F919.2050303@netconfcentral.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: NETCONF Subject: Re: [Netconf] with-defaults clarification 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, 05 Aug 2009 08:14:56 -0000 WashamFan wrote: > Hi, > >> >> The agent will use its internal defaults handling scheme >> when filling the candidate or running databases via copy-config. >> >> The with-defaults parameter is a filter for retrieval purposes. >> When transferring data INTO a database, the agent is allowed >> to populate the database with or without default leafs. >> This is part of the YANG spec, and with-defaults needs to be >> consistent with YANG rules. > > Thanks. Could you point out which part of YANG spec dealing with this? > 7.6.5 is one of them > washam > > Andy From andy@netconfcentral.com Wed Aug 5 01:22: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 8ED303A68A3 for ; Wed, 5 Aug 2009 01:22:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.494 X-Spam-Level: X-Spam-Status: No, score=-2.494 tagged_above=-999 required=5 tests=[AWL=0.105, 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 rv8s4Ajd5NSD for ; Wed, 5 Aug 2009 01:22:07 -0700 (PDT) Received: from smtp110.sbc.mail.mud.yahoo.com (smtp110.sbc.mail.mud.yahoo.com [68.142.198.209]) by core3.amsl.com (Postfix) with SMTP id A574C28C4D1 for ; Wed, 5 Aug 2009 01:22:07 -0700 (PDT) Received: (qmail 67241 invoked from network); 5 Aug 2009 08:22:04 -0000 Received: from unknown (HELO ?192.168.0.10?) (andy@67.125.157.61 with plain) by smtp110.sbc.mail.mud.yahoo.com with SMTP; 5 Aug 2009 08:22:04 -0000 X-YMail-OSG: 6qHaaMgVM1nQ3CD9.HXU7sZgESp1akc8WXXuHqkSH0MaZs_Uf3Rg5dV.qZ_LuXstm6ZG6MzeZrIkltkRHTgZaY2gJcpetCMOAGowLb0YGxtH0KpB8sdaN5D4MK6OBhIqxYOn4CZq1Esp.gfY6QX2yf1ishJevGA91c6_1Lr7RUo1V0PYWuOaurbZTjmSMGBfnKfuWlxF6qGmlkLEuiHTUN8FsvXulbrEfHdQ6kLzSSxdtAjO58nZGmwlGmzVLnHNxI49udBf07zNYvI- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4A794157.4070605@netconfcentral.com> Date: Wed, 05 Aug 2009 01:22:47 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.22 (X11/20090608) MIME-Version: 1.0 To: WashamFan References: <4A7473F3.5080709@netconfcentral.com> <25F318D5AD464AAB9D884EA06D23FAFC@BertLaptop> <4A760385.7050708@netconfcentral.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: NETCONF Subject: Re: [Netconf] partial locking for candidate and startup? 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, 05 Aug 2009 08:22:08 -0000 WashamFan wrote: > HI, > >> Bert Wijnen (IETF) wrote: >> > I anm not sure if we made that decision explicitly. >> > But I do know that we as a result of discussions/concerns/issues, >> we came to >> > this text (as currently in revision 09, which is in IESG review): >> > >> > 2.1.1. Usage Scenarios >> > >> > In the following we describe a few scenarios for partial locking. >> > Partial locking is primarily useful towards the running >> > configuration. However it can be used to lock parts of a candidate >> > datastore as well. While scenarios using the running datastore >> are >> > seen as the most important, as an example a scenario involving the >> > candidate datastore is also presented. Besides the three described >> > here, there are many other usage scenarios possible. >> > >> >> The use case in 2.1.1.3 is a mystery to me. >> >> I don't really see the point of locking my little >> section of the candidate scratchpad, then manually coordinating >> with all the other users (by email or SMS?) >> "is it OK to do a commit now?". > > How to do coordination is not clear in current text, but might be clear > in some body's mind. > A locking scheme that is voluntary may seem useful to your mind, but not mine. >> If even one user doesn't get the memo, >> and writes to the candidate ignoring all locks, >> then the edit-config might succeed. >> This can taint the commit -- either it will >> fail, or maybe a hacker will get somebody >> else to issue for some injected data under some other >> user's credentials. > > partial locking does not introduce this kind of vulnerability. it exists when > no locking used. no, it exists when partial-locking is used because there is no global lock in effect. A user which is either unaware of the voluntary cooperative lock, or is purposely trying to add config data to an unlocked portion of the candidate, will succeed. Depending on the access control model (if any), this extra data that will be committed by a different user may be OK or it may not let the commit finish. Global locks are not voluntary. The candidate config is global. Locking part of the candidate is just like not using any locks for all the unlocked parts. > >> Partial locking does not work for candidate. >> > partial locking on candidate MIGHT work for somebody. > > washam > > Andy From Washam.Fan@huaweisymantec.com Wed Aug 5 02:40: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 67C1028C54B for ; Wed, 5 Aug 2009 02:40:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.354 X-Spam-Level: X-Spam-Status: No, score=-0.354 tagged_above=-999 required=5 tests=[AWL=0.141, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RuGE3U3a-ypH for ; Wed, 5 Aug 2009 02:40:53 -0700 (PDT) Received: from mta1.huaweisymantec.com (unknown [218.17.155.14]) by core3.amsl.com (Postfix) with ESMTP id 98D1F3A6A5F for ; Wed, 5 Aug 2009 02:40:53 -0700 (PDT) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-disposition: inline Content-type: text/plain; charset=us-ascii Received: from hstml01-in.huaweisymantec.com ([172.26.3.41]) by hstga01-in.huaweisymantec.com (Sun Java(tm) System Messaging Server 6.3-8.03 (built Apr 24 2009; 32bit)) with ESMTP id <0KNW00ILDDJ4TN30@hstga01-in.huaweisymantec.com> for netconf@ietf.org; Wed, 05 Aug 2009 17:40:16 +0800 (CST) Received: from huaweisymantec.com ([127.0.0.1]) by hstml01-in.huaweisymantec.com (Sun Java(tm) System Messaging Server 6.3-8.03 (built Apr 24 2009; 32bit)) with ESMTP id <0KNW008RDDJ3NJ10@hstml01-in.huaweisymantec.com> for netconf@ietf.org; Wed, 05 Aug 2009 17:40:16 +0800 (CST) Received: from [10.27.154.141] by hstml01-in.huaweisymantec.com (mshttpd); Wed, 05 Aug 2009 17:40:15 +0800 From: WashamFan To: WashamFan Message-id: Date: Wed, 05 Aug 2009 17:40:15 +0800 X-Mailer: Sun Java(tm) System Messenger Express 6.3-8.03 (built Apr 24 2009; 32bit) Content-language: en X-Accept-Language: en Priority: normal In-reply-to: References: <20090803202203.GA20902@elstar.local> <4A7773BB.1080206@netconfcentral.com> <20090804095639.GA21611@elstar.local> <20090804114526.GB21708@elstar.local> <20090804124420.GA534@elstar.local> Cc: Netconf Subject: Re: [Netconf] Fw: Database Architecture OK or NOT-OK? 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, 05 Aug 2009 09:40:54 -0000 Hi, > Hi, > > > > That depends on how you see the changes between commits. If you > > > consider these changes as an additional part of previous undone > changes, > > > then they can be rollbacked. > > > > Not sure I understand your point. > > > > My model is that the start of a commit() defines the running > > configuration you roll back to if the commit fails. If this model > is > > right, then any further changes to the running configuration after > the > > start of the commit() will be lost - either because the commit > > succeeds or there is a rollback. Even use your model, why changes are lost when commit succeeds? When do those changes come? in the processing of or between confirmed commit and confirming commit? washam > Sorry, I misunderstood. I thought the changes via candidate, but you > meant the changes via running. That is different. > > washam From Washam.Fan@huaweisymantec.com Wed Aug 5 02:58:10 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 89E3628C551 for ; Wed, 5 Aug 2009 02:58:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.366 X-Spam-Level: X-Spam-Status: No, score=-0.366 tagged_above=-999 required=5 tests=[AWL=0.129, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LzpOe2PzPeCu for ; Wed, 5 Aug 2009 02:58:09 -0700 (PDT) Received: from mta2.huaweisymantec.com (unknown [218.17.155.15]) by core3.amsl.com (Postfix) with ESMTP id C3E2E28C39D for ; Wed, 5 Aug 2009 02:58:09 -0700 (PDT) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-disposition: inline Content-type: text/plain; charset=us-ascii Received: from hstml01-in.huaweisymantec.com ([172.26.3.42]) by hstga02-in.huaweisymantec.com (Sun Java(tm) System Messaging Server 6.3-8.03 (built Apr 24 2009; 32bit)) with ESMTP id <0KNW00LWHECPBE90@hstga02-in.huaweisymantec.com> for netconf@ietf.org; Wed, 05 Aug 2009 17:58:02 +0800 (CST) Received: from huaweisymantec.com ([127.0.0.1]) by hstml01-in.huaweisymantec.com (Sun Java(tm) System Messaging Server 6.3-8.03 (built Apr 24 2009; 32bit)) with ESMTP id <0KNW009TAECPY210@hstml01-in.huaweisymantec.com> for netconf@ietf.org; Wed, 05 Aug 2009 17:58:01 +0800 (CST) Received: from [10.27.154.141] by hstml01-in.huaweisymantec.com (mshttpd); Wed, 05 Aug 2009 17:58:01 +0800 From: WashamFan To: Juergen Schoenwaelder Message-id: Date: Wed, 05 Aug 2009 17:58:01 +0800 X-Mailer: Sun Java(tm) System Messenger Express 6.3-8.03 (built Apr 24 2009; 32bit) Content-language: en X-Accept-Language: en Priority: normal In-reply-to: <20090804211449.GA1307@elstar.local> References: <20090803202203.GA20902@elstar.local> <4A7773BB.1080206@netconfcentral.com> <20090804095639.GA21611@elstar.local> <4A784734.7080201@netconfcentral.com> <20090804144838.GA962@elstar.local> <4A784E8E.8000007@netconfcentral.com> <20090804184136.GC1038@elstar.local> <4A788A66.4030106@bwijnen.net> <20090804211449.GA1307@elstar.local> Cc: Netconf Subject: Re: [Netconf] Fw: Database Architecture OK or NOT-OK? 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, 05 Aug 2009 09:58:10 -0000 Hi, > Also note that unlock('candidate') reverts candidate back to 'running' > - but I have less an issue with that (although I probably would not > have designed things this way myself). If changes to running are allowed when candidate is locked, then how to deal with changes coming in between and . That might be the reason why some people add syncing to unlock. washam From Washam.Fan@huaweisymantec.com Wed Aug 5 03:00: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 768933A711E for ; Wed, 5 Aug 2009 03:00:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.376 X-Spam-Level: X-Spam-Status: No, score=-0.376 tagged_above=-999 required=5 tests=[AWL=0.119, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u3PK3shTA91D for ; Wed, 5 Aug 2009 03:00:00 -0700 (PDT) Received: from mta2.huaweisymantec.com (unknown [218.17.155.15]) by core3.amsl.com (Postfix) with ESMTP id 0FB1728C551 for ; Wed, 5 Aug 2009 02:59:53 -0700 (PDT) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-disposition: inline Content-type: text/plain; charset=us-ascii Received: from hstml01-in.huaweisymantec.com ([172.26.3.42]) by hstga02-in.huaweisymantec.com (Sun Java(tm) System Messaging Server 6.3-8.03 (built Apr 24 2009; 32bit)) with ESMTP id <0KNW00LXREFLBE90@hstga02-in.huaweisymantec.com> for netconf@ietf.org; Wed, 05 Aug 2009 17:59:45 +0800 (CST) Received: from huaweisymantec.com ([127.0.0.1]) by hstml01-in.huaweisymantec.com (Sun Java(tm) System Messaging Server 6.3-8.03 (built Apr 24 2009; 32bit)) with ESMTP id <0KNW009OTEFLAW10@hstml01-in.huaweisymantec.com> for netconf@ietf.org; Wed, 05 Aug 2009 17:59:45 +0800 (CST) Received: from [10.27.154.141] by hstml01-in.huaweisymantec.com (mshttpd); Wed, 05 Aug 2009 17:59:45 +0800 From: WashamFan To: Andy Bierman Message-id: Date: Wed, 05 Aug 2009 17:59:45 +0800 X-Mailer: Sun Java(tm) System Messenger Express 6.3-8.03 (built Apr 24 2009; 32bit) Content-language: en X-Accept-Language: en Priority: normal In-reply-to: <4A78AA22.4070405@netconfcentral.com> References: <20090803202203.GA20902@elstar.local> <4A7773BB.1080206@netconfcentral.com> <20090804095639.GA21611@elstar.local> <4A784734.7080201@netconfcentral.com> <20090804144838.GA962@elstar.local> <4A784E8E.8000007@netconfcentral.com> <20090804184136.GC1038@elstar.local> <4A788A66.4030106@bwijnen.net> <20090804211449.GA1307@elstar.local> <4A78AA22.4070405@netconfcentral.com> Cc: Netconf Subject: Re: [Netconf] Fw: Database Architecture OK or NOT-OK? 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, 05 Aug 2009 10:00:01 -0000 > Note that the agent MUST send the session-id of the > lock-holder (lock-denied error-tag), but in this case, > there is no lock holder. > > Is the agent supposed to send session-id=0 in this case? > That will look like SNMP or CLI has the lock. > session-id makes no sense in above case, since no one has the lock. I don't think we need session-id field in this case. washam From Washam.Fan@huaweisymantec.com Wed Aug 5 03:10: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 AE3FA3A6D2D for ; Wed, 5 Aug 2009 03:10:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.384 X-Spam-Level: X-Spam-Status: No, score=-0.384 tagged_above=-999 required=5 tests=[AWL=0.111, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PwfZhV7K4sKO for ; Wed, 5 Aug 2009 03:10:30 -0700 (PDT) Received: from mta2.huaweisymantec.com (unknown [218.17.155.15]) by core3.amsl.com (Postfix) with ESMTP id D8CD93A7113 for ; Wed, 5 Aug 2009 03:10:29 -0700 (PDT) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-disposition: inline Content-type: text/plain; charset=us-ascii Received: from hstml01-in.huaweisymantec.com ([172.26.3.42]) by hstga02-in.huaweisymantec.com (Sun Java(tm) System Messaging Server 6.3-8.03 (built Apr 24 2009; 32bit)) with ESMTP id <0KNW00L2SEXABEA0@hstga02-in.huaweisymantec.com> for netconf@ietf.org; Wed, 05 Aug 2009 18:10:22 +0800 (CST) Received: from huaweisymantec.com ([127.0.0.1]) by hstml01-in.huaweisymantec.com (Sun Java(tm) System Messaging Server 6.3-8.03 (built Apr 24 2009; 32bit)) with ESMTP id <0KNW00AT2EX96O10@hstml01-in.huaweisymantec.com> for netconf@ietf.org; Wed, 05 Aug 2009 18:10:22 +0800 (CST) Received: from [10.27.154.141] by hstml01-in.huaweisymantec.com (mshttpd); Wed, 05 Aug 2009 18:10:21 +0800 From: WashamFan To: Andy Bierman Message-id: Date: Wed, 05 Aug 2009 18:10:21 +0800 X-Mailer: Sun Java(tm) System Messenger Express 6.3-8.03 (built Apr 24 2009; 32bit) Content-language: en X-Accept-Language: en Priority: normal In-reply-to: <4A78ABE4.4010403@netconfcentral.com> References: <20090803202203.GA20902@elstar.local> <4A7773BB.1080206@netconfcentral.com> <20090804095639.GA21611@elstar.local> <4A784734.7080201@netconfcentral.com> <20090804144838.GA962@elstar.local> <4A784E8E.8000007@netconfcentral.com> <20090804184136.GC1038@elstar.local> <4A788A66.4030106@bwijnen.net> <20090804211449.GA1307@elstar.local> <4A78ABE4.4010403@netconfcentral.com> Cc: Netconf Subject: Re: [Netconf] Fw: Database Architecture OK or NOT-OK? 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, 05 Aug 2009 10:10:30 -0000 Hi, > Can we change this in 4741bis? > Why is the candidate so special? > I don't get it at all. Are you saying to remove the belowing criterion for identifying a invalid lock: The target configuration is , it has already been modified, and these changes have not been committed or rolled back. > If the user doesn't use locking, > then too bad, so sad. Somebody > else can just discard your changes > without any lock, so what is the point of > preventing a lock once you have touched the candidate somehow? use a (global) lock when you see potential interruption. otherwise no lock used in a controllable enviroment. It is up to you. washam > The loop should go away. > The lock should succeed on candidate, unless it is > currently locked. Then the discard-changes > command could go after the lock was granted, > and there would be no confusion wrt/ lock-denied yet no session > is holding the lock. > > > > /js > > > > Andy > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf > From Washam.Fan@huaweisymantec.com Wed Aug 5 03:30: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 C52C828C550 for ; Wed, 5 Aug 2009 03:30:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.392 X-Spam-Level: X-Spam-Status: No, score=-0.392 tagged_above=-999 required=5 tests=[AWL=0.103, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tqvDGpkn9aZ9 for ; Wed, 5 Aug 2009 03:30:05 -0700 (PDT) Received: from mta2.huaweisymantec.com (unknown [218.17.155.15]) by core3.amsl.com (Postfix) with ESMTP id 98EE828C544 for ; Wed, 5 Aug 2009 03:30:04 -0700 (PDT) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-disposition: inline Content-type: text/plain; charset=us-ascii Received: from hstml01-in.huaweisymantec.com ([172.26.3.42]) by hstga02-in.huaweisymantec.com (Sun Java(tm) System Messaging Server 6.3-8.03 (built Apr 24 2009; 32bit)) with ESMTP id <0KNW00LGSCVOBE90@hstga02-in.huaweisymantec.com> for netconf@ietf.org; Wed, 05 Aug 2009 17:26:12 +0800 (CST) Received: from huaweisymantec.com ([127.0.0.1]) by hstml01-in.huaweisymantec.com (Sun Java(tm) System Messaging Server 6.3-8.03 (built Apr 24 2009; 32bit)) with ESMTP id <0KNW009Q3CVOQK10@hstml01-in.huaweisymantec.com> for netconf@ietf.org; Wed, 05 Aug 2009 17:26:12 +0800 (CST) Received: from [10.27.154.141] by hstml01-in.huaweisymantec.com (mshttpd); Wed, 05 Aug 2009 17:26:12 +0800 From: WashamFan To: Andy Bierman Message-id: Date: Wed, 05 Aug 2009 17:26:12 +0800 X-Mailer: Sun Java(tm) System Messenger Express 6.3-8.03 (built Apr 24 2009; 32bit) Content-language: en X-Accept-Language: en Priority: normal In-reply-to: <4A794157.4070605@netconfcentral.com> References: <4A7473F3.5080709@netconfcentral.com> <25F318D5AD464AAB9D884EA06D23FAFC@BertLaptop> <4A760385.7050708@netconfcentral.com> <4A794157.4070605@netconfcentral.com> Cc: NETCONF Subject: Re: [Netconf] partial locking for candidate and startup? 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, 05 Aug 2009 10:30:05 -0000 Hi, > >> If even one user doesn't get the memo, > >> and writes to the candidate ignoring all locks, > >> then the edit-config might succeed. > >> This can taint the commit -- either it will > >> fail, or maybe a hacker will get somebody > >> else to issue for some injected data under some other > >> user's credentials. > > > > partial locking does not introduce this kind of vulnerability. it > exists when > > no locking used. > > no, it exists when partial-locking is used because > there is no global lock in effect. A user which is > either unaware of the voluntary cooperative lock, > or is purposely trying to add config data to an > unlocked portion of the candidate, will succeed. > > Depending on the access control model (if any), > this extra data that will be committed by a different > user may be OK or it may not let the commit finish. > > Global locks are not voluntary. > The candidate config is global. > Locking part of the candidate is just like not using any > locks for all the unlocked parts. I totally agreed with what you said. But what I meant was if you don't use lock (regardless of glocal or partial locks) at all, you face this vulnerability, either. The point is if you consider this as a threat, please use global lock, otherwise, you can use partial locks or no lock at all. Locks (regardless of global or partial locks) can not resolve all problems. they aim to coordinate the at-the-time writes to locked objects. If you think potential interruption to the whole config, grab a global lock, otherwise a partial lock or no lock is OK. We may on the same side. washam From j.schoenwaelder@jacobs-university.de Wed Aug 5 04:10: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 8D92A3A69E5 for ; Wed, 5 Aug 2009 04:10:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.21 X-Spam-Level: X-Spam-Status: No, score=-2.21 tagged_above=-999 required=5 tests=[AWL=0.039, 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 UanwCvAzdp+R for ; Wed, 5 Aug 2009 04:10:42 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 2DF543A6B92 for ; Wed, 5 Aug 2009 04:10:42 -0700 (PDT) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 6CA42C0064; Wed, 5 Aug 2009 13:10:44 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius4.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 5flls-LXbcyf; Wed, 5 Aug 2009 13:10:43 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id A854BC0063; Wed, 5 Aug 2009 13:10:42 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 91D29B79502; Wed, 5 Aug 2009 13:10:41 +0200 (CEST) Date: Wed, 5 Aug 2009 13:10:41 +0200 From: Juergen Schoenwaelder To: Andy Bierman Message-ID: <20090805111041.GC1630@elstar.local> Mail-Followup-To: Andy Bierman , "Bert (IETF) Wijnen" , Netconf References: <20090803202203.GA20902@elstar.local> <4A7773BB.1080206@netconfcentral.com> <20090804095639.GA21611@elstar.local> <4A784734.7080201@netconfcentral.com> <20090804144838.GA962@elstar.local> <4A784E8E.8000007@netconfcentral.com> <20090804184136.GC1038@elstar.local> <4A788A66.4030106@bwijnen.net> <20090804211449.GA1307@elstar.local> <4A78A676.3010308@netconfcentral.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4A78A676.3010308@netconfcentral.com> User-Agent: Mutt/1.5.19 (2009-01-05) Cc: Netconf Subject: Re: [Netconf] Fw: Database Architecture OK or NOT-OK? 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, 05 Aug 2009 11:10:48 -0000 On Tue, Aug 04, 2009 at 11:21:58PM +0200, Andy Bierman wrote: > Juergen Schoenwaelder wrote: > > On Tue, Aug 04, 2009 at 09:22:14PM +0200, Bert (IETF) Wijnen wrote: > >> Juergen Schoenwaelder wrote: > >>> I would probably issue a discard-changes() whenever I want to use > >>> 'candidate' so I can be sure what its contents is. And since > >>> discard-changes() and lock('candidate') are not atomic, the real code > >>> likely becomes this: > >>> > >>> lock('running') > >>> do { > >>> discard-changes() > >>> lock('candidate') > >>> } until lock-aquired > >>> edit-config('candidate', ...) > >>> commit() > >>> unlock('candidate') > >>> unlock('running') > >>> > >>> > >> would you not rather first get the lock on candidate before you do a > >> discard-changes ?? > >> otherwise someone else might still change the candidate in between your > >> discard-changes and lock, no? > > > > The NETCONF RFC says that lock('candidate') fails if 'candidate' is > > dirty. So you have to clean 'candidate' before you can get the lock > > and since discarding changes and locking is not atomic, you get a loop > > like above. > > > > Also note that unlock('candidate') reverts candidate back to 'running' > > - but I have less an issue with that (although I probably would not > > have designed things this way myself). > > > > Not in my code. > I don't see that anywhere in sec. 7.6. > Losing the lock via session termination doesn't even > revert the candidate. This is 1 reason why the candidate > may be dirty in the first place. Check out section 8.3.5.2. - :candidate adds special behaviour to lock operations. When a client fails with outstanding changes to the candidate configuration, recovery can be difficult. To facilitate easy recovery, any outstanding changes are discarded when the lock is released, whether explicitly with the operation or implicitly from session failure. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From j.schoenwaelder@jacobs-university.de Wed Aug 5 04:13: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 01CCF3A7184 for ; Wed, 5 Aug 2009 04:13:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.211 X-Spam-Level: X-Spam-Status: No, score=-2.211 tagged_above=-999 required=5 tests=[AWL=0.038, 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 qGP3ON6XnIyI for ; Wed, 5 Aug 2009 04:13:29 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 29FB33A691A for ; Wed, 5 Aug 2009 04:13:29 -0700 (PDT) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id BF1E2C0064; Wed, 5 Aug 2009 13:13:31 +0200 (CEST) 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 F8DIA8aOdlc0; Wed, 5 Aug 2009 13:13:31 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 1C6C5C0063; Wed, 5 Aug 2009 13:13:31 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id F228CB79560; Wed, 5 Aug 2009 13:13:29 +0200 (CEST) Date: Wed, 5 Aug 2009 13:13:29 +0200 From: Juergen Schoenwaelder To: Andy Bierman Message-ID: <20090805111329.GD1630@elstar.local> Mail-Followup-To: Andy Bierman , "Bert (IETF) Wijnen" , Netconf References: <20090803202203.GA20902@elstar.local> <4A7773BB.1080206@netconfcentral.com> <20090804095639.GA21611@elstar.local> <4A784734.7080201@netconfcentral.com> <20090804144838.GA962@elstar.local> <4A784E8E.8000007@netconfcentral.com> <20090804184136.GC1038@elstar.local> <4A788A66.4030106@bwijnen.net> <20090804211449.GA1307@elstar.local> <4A78ABE4.4010403@netconfcentral.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4A78ABE4.4010403@netconfcentral.com> User-Agent: Mutt/1.5.19 (2009-01-05) Cc: Netconf Subject: Re: [Netconf] Fw: Database Architecture OK or NOT-OK? 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, 05 Aug 2009 11:13:30 -0000 On Tue, Aug 04, 2009 at 11:45:08PM +0200, Andy Bierman wrote: > The loop should go away. > The lock should succeed on candidate, unless it is > currently locked. Then the discard-changes > command could go after the lock was granted, > and there would be no confusion wrt/ lock-denied yet no session > is holding the lock. This was the code I originally wrote until I was made aware that lock()/unlock() semantics are special for 'candidate' and since you were also not really aware of this, we have at least two cases where people were caught by a surprise (and I might count Bert's email as an indication of a 3rd case of surprise). /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From j.schoenwaelder@jacobs-university.de Wed Aug 5 04:17: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 ACB123A691A for ; Wed, 5 Aug 2009 04:17:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.212 X-Spam-Level: X-Spam-Status: No, score=-2.212 tagged_above=-999 required=5 tests=[AWL=0.037, 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 XEarOMHpsa9k for ; Wed, 5 Aug 2009 04:17:37 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 92D963A6B92 for ; Wed, 5 Aug 2009 04:17:37 -0700 (PDT) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 13CDFC0065; Wed, 5 Aug 2009 13:17:40 +0200 (CEST) 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 sHUqwqm97uqb; Wed, 5 Aug 2009 13:17:39 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id CD195C0064; Wed, 5 Aug 2009 13:17:38 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id B5D19B795B0; Wed, 5 Aug 2009 13:17:37 +0200 (CEST) Date: Wed, 5 Aug 2009 13:17:37 +0200 From: Juergen Schoenwaelder To: WashamFan Message-ID: <20090805111737.GE1630@elstar.local> Mail-Followup-To: WashamFan , "Bert (IETF) Wijnen" , Netconf References: <20090803202203.GA20902@elstar.local> <4A7773BB.1080206@netconfcentral.com> <20090804095639.GA21611@elstar.local> <4A784734.7080201@netconfcentral.com> <20090804144838.GA962@elstar.local> <4A784E8E.8000007@netconfcentral.com> <20090804184136.GC1038@elstar.local> <4A788A66.4030106@bwijnen.net> <20090804211449.GA1307@elstar.local> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.19 (2009-01-05) Cc: Netconf Subject: Re: [Netconf] Fw: Database Architecture OK or NOT-OK? 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, 05 Aug 2009 11:17:38 -0000 On Wed, Aug 05, 2009 at 11:58:01AM +0200, WashamFan wrote: > Hi, > > > Also note that unlock('candidate') reverts candidate back to 'running' > > - but I have less an issue with that (although I probably would not > > have designed things this way myself). > > If changes to running are allowed when candidate is locked, then how to > deal with changes coming in between and . That might > be the reason why some people add syncing to unlock. My understanding is that unlock() does an implicit discard-changes() or copy-config('candidate', 'running') - so I do not understand your question. My concern really is that :candidate adds semantics to lock()/unlock() that are subtle and it remains unclear to me why they are needed - perhaps Phil can try to explain this again. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From balazs.lengyel@ericsson.com Wed Aug 5 04:54: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 786E63A679F; Wed, 5 Aug 2009 04:54:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.195 X-Spam-Level: X-Spam-Status: No, score=-5.195 tagged_above=-999 required=5 tests=[AWL=0.454, BAYES_00=-2.599, HELO_EQ_SE=0.35, J_CHICKENPOX_43=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 hYY+Y3OSgsko; Wed, 5 Aug 2009 04:54:36 -0700 (PDT) Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by core3.amsl.com (Postfix) with ESMTP id 7AC963A69FB; Wed, 5 Aug 2009 04:54:13 -0700 (PDT) X-AuditID: c1b4fb3e-b7b53ae000004f0b-a7-4a7972e60560 Received: from esealmw127.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw4.ericsson.se (Symantec Mail Security) with SMTP id B6.74.20235.6E2797A4; Wed, 5 Aug 2009 13:54:14 +0200 (CEST) Received: from esealmw129.eemea.ericsson.se ([153.88.254.177]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Wed, 5 Aug 2009 13:54:08 +0200 Received: from [159.107.197.224] ([159.107.197.224]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Wed, 5 Aug 2009 13:54:08 +0200 Message-ID: <4A7972DF.7000202@ericsson.com> Date: Wed, 05 Aug 2009 13:54:07 +0200 From: Balazs Lengyel User-Agent: Thunderbird 2.0.0.4 (X11/20070604) MIME-Version: 1.0 To: Adrian Farrel References: <20090802171214.428EB3A6995@core3.amsl.com> In-Reply-To: <20090802171214.428EB3A6995@core3.amsl.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 05 Aug 2009 11:54:08.0275 (UTC) FILETIME=[70712630:01CA15C3] X-Brightmail-Tracker: AAAAAA== Cc: draft-ietf-netconf-partial-lock@tools.ietf.org, iesg@ietf.org, netconf-chairs@tools.ietf.org, netconf mailing list Subject: Re: [Netconf] DISCUSS: draft-ietf-netconf-partial-lock 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, 05 Aug 2009 11:54:37 -0000 Hello Adrian, Thanks for the comments. See my answers below! regards Balazs Adrian Farrel wrote: > Discuss: > > If I read it right, in 2.4.1 where you have... > A partial lock operation MUST fail if: > > o Any NETCONF session (including the current session) owns the > global lock on any target datastore. > ...you are saying that if I want to drop down from the global lock to > a partial lock, I must first unlock everything and then take up the > partial lock. Of course, this opens up a small window, so the > application is encouraged (in order to not open the window) to retain > the global lock longer than needed. Did you consider letting a session > take up a partial lock and then release the global lock (in exactly the > way overlapping partial locks are allowed at the same time - since the > global lock is only a special case of a partial lock!) > > Ditto the reverse case. That is, why can't a session holding a partial > lock increase this to the global lock without first releaseing the > partial lock (and opening a window). This is less of an issue because > the session could grab a second, overlapping partial lock that includes > every node. That might be messy, but achieves the desired function. BALAZS: The exact same question was debated in the WG with the conclusion: - For compatibility reasons don't change how the (global) lock works in rfc4741. There it says: "An attempt to lock the configuration MUST fail if an existing session or other entity holds a lock on any portion of the lock target." This means going from a partial to a global lock is not allowed without releasing the partial lock. - Don't allow a session to hold both a partial and global lock at the same time. There is no real need and this method makes implementation more simple. If we don't allow partial lock and later the global lock(see above), allowing global and afterwards a partial lock would be confusing. The correct procedure should be that the user starts with partial locking immediately, in extreme with a partial lock that covers the entire datastore. This way he can reduce the scope of partial locking without any unlocked interval. - > > === > > I think that the XML examples in 2.4.1.1 etc., schema in Appendix A, > and YANG in Appendix B qualify for code license statements. BALAZS: See separate mail. I will follow the correct procedure. > > === > > I'm sure security has been extensively debated in the context of > RFC 4741 and I don't want to rehash any debates. > > I wondered whether (2.4.1.1)... > > Negative Response: > > If a lock is already held by another session on any node within the > subtrees to be locked, the element is 'lock-denied' and > the element includes the of the lock owner. > > ...was potentially giving out more information than necesary/desirbale. > Probably you need to state that the filter (2.4.1.1)... > > If access control denies the partial lock, the is > 'access-denied'. > > ...and (3.)... > > Only an authenticated and authorized user can request a partial > lock. BALAZS: It is a property of the NETCONF protocol, that only authenticated users can request any operation. So IMO we don't have to deal with the issue here. From rfc4741: "NETCONF connections must provide authentication..." > > ...SHOULD be evaluated first. Otherwise, an unauthrised user can easily > determine the identities of the authorised users. In 2.4.1.1 this will > need reordering of the text as well as the "SHOULD" statement. BALAZS: The rpc-reply only gives back the sessionId of the locking user not the userId. I don't see much risk associated with the sessionId. At most the attacker may determine the number of live Netconf sessions, but that can be inferred from the number of TCP connections to the dedicated NETCONF port(s) as well. BALAZS: checking access control before checking for conflicting locks seems to be a good idea. I will add the text : "Access control SHOULD be checked before checking for conflicting locks to avoid giving out information about other sessions to an unauthorized client." > > It also seemed to me that (3.) ... > > A lock that is hung for some reason (e.g., a broken TCP connection > that the server has not yet recognised) can be released using another > NETCONF session by explicitly killing the session owning that lock > using the operation. > > ...seemed quite an amusing attack. But I presume that the session > issuing the is suitably qualified. BALAZS: Yes, from NETCONF rfc4741: "NETCONF connections must provide authentication..." "Implementors SHOULD provide a comprehensive authorization scheme with NETCONF." Anyway this has not been changed compared to rfc4741. > > === > > 2.4.2. > > The operation unlocks the parts of the datastores that were > previously locked using during the same session. > > This is not true in the case of overlapping partial locks as previously > described. Just need to tweak the text a little. BALAZS: OK. Added: "The operation unlocks the parts that are covered by the lock identified by the lock-id parameter." > > -- Balazs Lengyel Ericsson Hungary Ltd. System Manager ECN: 831 7320 Fax: +36 1 4377792 Tel: +36-1-437-7320 email: Balazs.Lengyel@ericsson.com From balazs.lengyel@ericsson.com Wed Aug 5 05:21: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 E7B063A69B1 for ; Wed, 5 Aug 2009 05:21:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.516 X-Spam-Level: X-Spam-Status: No, score=-5.516 tagged_above=-999 required=5 tests=[AWL=0.733, 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 U0g6E4BWqUYN for ; Wed, 5 Aug 2009 05:21:16 -0700 (PDT) Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by core3.amsl.com (Postfix) with ESMTP id D7A823A68D7 for ; Wed, 5 Aug 2009 05:21:15 -0700 (PDT) X-AuditID: c1b4fb3c-b7b51ae000003b25-f7-4a79793c96e3 Received: from esealmw126.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw3.ericsson.se (Symantec Mail Security) with SMTP id 10.AD.15141.C39797A4; Wed, 5 Aug 2009 14:21:17 +0200 (CEST) Received: from esealmw126.eemea.ericsson.se ([153.88.254.174]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Wed, 5 Aug 2009 14:21:16 +0200 Received: from [159.107.197.224] ([159.107.197.224]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Wed, 5 Aug 2009 14:21:16 +0200 Message-ID: <4A79793C.5080502@ericsson.com> Date: Wed, 05 Aug 2009 14:21:16 +0200 From: Balazs Lengyel User-Agent: Thunderbird 2.0.0.4 (X11/20070604) MIME-Version: 1.0 To: Andy Bierman References: <4A71D2E9.4080004@netconfcentral.com> In-Reply-To: <4A71D2E9.4080004@netconfcentral.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 05 Aug 2009 12:21:16.0811 (UTC) FILETIME=[3B2005B0:01CA15C7] X-Brightmail-Tracker: AAAAAA== Cc: NETCONF Subject: Re: [Netconf] with-defaults clarification 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, 05 Aug 2009 12:21:17 -0000 Hello Andy, The draft says in chapter 2.5 " is only affected if the target of the operation is a URL." Balazs Andy Bierman wrote: > Hi, > > I think the with-defaults draft should be clarified to > indicate that the parameter is ignored > for if the target of the copy operation > is the candidate or running databases. > > > Andy > > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf > -- Balazs Lengyel Ericsson Hungary Ltd. System Manager ECN: 831 7320 Fax: +36 1 4377792 Tel: +36-1-437-7320 email: Balazs.Lengyel@ericsson.com From balazs.lengyel@ericsson.com Wed Aug 5 05:40: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 4AC9A28C53B for ; Wed, 5 Aug 2009 05:40:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.548 X-Spam-Level: X-Spam-Status: No, score=-3.548 tagged_above=-999 required=5 tests=[AWL=-1.299, BAYES_00=-2.599, HELO_EQ_SE=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 fCe+pGRynlWB for ; Wed, 5 Aug 2009 05:40:11 -0700 (PDT) Received: from mailgw5.ericsson.se (mailgw5.ericsson.se [193.180.251.36]) by core3.amsl.com (Postfix) with ESMTP id E7C2828C553 for ; Wed, 5 Aug 2009 05:39:16 -0700 (PDT) X-AuditID: c1b4fb24-b7c01ae00000498b-16-4a797d6a3e22 Received: from esealmw126.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw5.ericsson.se (Symantec Brightmail Gateway) with SMTP id 8F.66.18827.A6D797A4; Wed, 5 Aug 2009 14:39:06 +0200 (CEST) Received: from esealmw128.eemea.ericsson.se ([153.88.254.172]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Wed, 5 Aug 2009 14:39:06 +0200 Received: from [159.107.197.224] ([159.107.197.224]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Wed, 5 Aug 2009 14:39:05 +0200 Message-ID: <4A797D69.4040400@ericsson.com> Date: Wed, 05 Aug 2009 14:39:05 +0200 From: Balazs Lengyel User-Agent: Thunderbird 2.0.0.4 (X11/20070604) MIME-Version: 1.0 To: Andy Bierman References: <4A71D2E9.4080004@netconfcentral.com> <4A783CAD.3090301@netconfcentral.com> <4A78F919.2050303@netconfcentral.com> In-Reply-To: <4A78F919.2050303@netconfcentral.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 05 Aug 2009 12:39:06.0001 (UTC) FILETIME=[B8697810:01CA15C9] X-Brightmail-Tracker: AAAAAA== Cc: NETCONF Subject: Re: [Netconf] with-defaults clarification 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, 05 Aug 2009 12:40:12 -0000 Hello, The aim of the with-defaults capability is to allow a manager to decide if it wants to receive the defaults. From the abstract: "This document defines a capability-based extension to the NETCONF protocol that allows the NETCONF manager to control whether default values are part of NETCONF messages." Copying something into running/candidate/startup is clearly out of scope. It does not go to the manager. How copy from URL to datastore works is specified in YANG, so no work needed there. Copy from datastore to datastore should not modify defaults as, I believe a device will handle defaults the same way in all datastores (do we need to specify this in some draft e.g. 4741bis?). Turning default values into explicitly defined default values is an edit-config like operation, it should not be a side effect of copy-config. For some devices (Juniper) this really modifies the config, so it should be a separate operation, if we need it. Balazs Andy Bierman wrote: > WashamFan wrote: >> Hi, >> >>> >> Hi, >>> >> >>> >> I think the with-defaults draft should be clarified to >>> >> indicate that the parameter is ignored >>> >> for if the target of the copy operation >>> >> is the candidate or running databases. >>> > >>> > What does "ignored" herein exactly mean? How to handle default data >>> if >>> > we "ignored" ? >>> > >>> > As discussed in subsequent mails, it is up to operator to decide how >>> > to handle the defaults, so why bother to dictate operator should ignore >>> > or comply with the ? >>> > >>> >>> Note the direction of the copy-config here. >>> This is for data going into the candidate or running config, >>> not data retrieved from it. >>> >>> Ignored means "has no affect". >> The agent should handle default data regardless of ignoring or not. >> Are you saying "ignored" means agent can handle default data at its will? >> (I.e., agent might trim defaults, might report all defaults, which depends >> on intrinsic implementation) >> > > The agent will use its internal defaults handling scheme > when filling the candidate or running databases via copy-config. > > The with-defaults parameter is a filter for retrieval purposes. > When transferring data INTO a database, the agent is allowed > to populate the database with or without default leafs. > This is part of the YANG spec, and with-defaults needs to be > consistent with YANG rules. > > >> washam >> >> > > Andy > > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf > -- Balazs Lengyel Ericsson Hungary Ltd. System Manager ECN: 831 7320 Fax: +36 1 4377792 Tel: +36-1-437-7320 email: Balazs.Lengyel@ericsson.com From andy@netconfcentral.com Wed Aug 5 06: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 4B5463A6AF8 for ; Wed, 5 Aug 2009 06:02:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.496 X-Spam-Level: X-Spam-Status: No, score=-2.496 tagged_above=-999 required=5 tests=[AWL=0.103, 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 fXQlxVOzVFoU for ; Wed, 5 Aug 2009 06:02:15 -0700 (PDT) Received: from smtp114.sbc.mail.mud.yahoo.com (smtp114.sbc.mail.mud.yahoo.com [68.142.198.213]) by core3.amsl.com (Postfix) with SMTP id 78CC03A6814 for ; Wed, 5 Aug 2009 06:02:15 -0700 (PDT) Received: (qmail 17880 invoked from network); 5 Aug 2009 13:02:14 -0000 Received: from unknown (HELO ?192.168.0.10?) (andy@67.125.157.61 with plain) by smtp114.sbc.mail.mud.yahoo.com with SMTP; 5 Aug 2009 13:02:14 -0000 X-YMail-OSG: dbfH0NQVM1nZVU86ITeJBYxsjA3Ibdn4DJGt9USsr0iQe75CYrPtzBSaSKQ.VpY5BWRkXzFGGfjwxY.d_9pQH9Jv89lEj7k0jVY1KMi8gTqRjnkRp7lU3RqD1zzxSTWwP35fZaBCESXqyAPy9YURXt3JhS5OeZY54ceDE1_NBn_wZuLX0EW1hInzl4bC0uuig3KiDw.YDP4vbVO8CtM_8zoANtymRWhPx93wd6bwlVp1lAAidFbjAeBrb1nYKpsG4KYhlXxeAH1Iuew- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4A798302.9020007@netconfcentral.com> Date: Wed, 05 Aug 2009 06:02:58 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.22 (X11/20090608) MIME-Version: 1.0 To: Andy Bierman , "Bert (IETF) Wijnen" , Netconf References: <20090803202203.GA20902@elstar.local> <4A7773BB.1080206@netconfcentral.com> <20090804095639.GA21611@elstar.local> <4A784734.7080201@netconfcentral.com> <20090804144838.GA962@elstar.local> <4A784E8E.8000007@netconfcentral.com> <20090804184136.GC1038@elstar.local> <4A788A66.4030106@bwijnen.net> <20090804211449.GA1307@elstar.local> <4A78ABE4.4010403@netconfcentral.com> <20090805111329.GD1630@elstar.local> In-Reply-To: <20090805111329.GD1630@elstar.local> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [Netconf] Fw: Database Architecture OK or NOT-OK? 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, 05 Aug 2009 13:02:16 -0000 Juergen Schoenwaelder wrote: > On Tue, Aug 04, 2009 at 11:45:08PM +0200, Andy Bierman wrote: > >> The loop should go away. >> The lock should succeed on candidate, unless it is >> currently locked. Then the discard-changes >> command could go after the lock was granted, >> and there would be no confusion wrt/ lock-denied yet no session >> is holding the lock. > > This was the code I originally wrote until I was made aware that > lock()/unlock() semantics are special for 'candidate' and since > you were also not really aware of this, we have at least two cases > where people were caught by a surprise (and I might count Bert's > email as an indication of a 3rd case of surprise). > I should not be surprised. I should have guessed, because for candidate, the least likely behavior is probably how it works. Good to know if you mistakenly ^C out of a program, that NETCONF's got your back by blowing away any changes to candidate you obviously don't want anymore. Oh, you did want to keep those edits? Too bad. > /js > Andy From balazs.lengyel@ericsson.com Wed Aug 5 06:11: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 39ADE3A7003 for ; Wed, 5 Aug 2009 06:11:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.494 X-Spam-Level: X-Spam-Status: No, score=-5.494 tagged_above=-999 required=5 tests=[AWL=0.755, 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 t36Nd2nqczaq for ; Wed, 5 Aug 2009 06:11:13 -0700 (PDT) Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by core3.amsl.com (Postfix) with ESMTP id 6BAFD3A6C76 for ; Wed, 5 Aug 2009 06:11:12 -0700 (PDT) X-AuditID: c1b4fb3c-b7b51ae000003b25-00-4a7984eef4c9 Received: from esealmw127.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw3.ericsson.se (Symantec Mail Security) with SMTP id 6A.21.15141.EE4897A4; Wed, 5 Aug 2009 15:11:10 +0200 (CEST) Received: from esealmw129.eemea.ericsson.se ([153.88.254.177]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Wed, 5 Aug 2009 15:11:07 +0200 Received: from [159.107.197.224] ([159.107.197.224]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Wed, 5 Aug 2009 15:11:07 +0200 Message-ID: <4A7984EA.4000703@ericsson.com> Date: Wed, 05 Aug 2009 15:11:06 +0200 From: Balazs Lengyel User-Agent: Thunderbird 2.0.0.4 (X11/20070604) MIME-Version: 1.0 To: netconf mailing list Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 05 Aug 2009 13:11:07.0150 (UTC) FILETIME=[31818AE0:01CA15CE] X-Brightmail-Tracker: AAAAAA== Subject: [Netconf] [Fwd: New Version Notification for draft-ietf-netconf-with-defaults-03] 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, 05 Aug 2009 13:11:14 -0000 Hello, Sorry for doing this in the middle of WG Last call, but I posted a new draft. I realized that it would be important to include the non-normative YAM in the WG last call. Other changes: - included Phil's comments - changed the URIs so if we ever get the YAM to be normative, we should only need to advertise one URI and not two. Balazs PS. I will be mostly unavailable till the 25th so might be slow to answer comments. -------- Original Message -------- Subject: New Version Notification for draft-ietf-netconf-with-defaults-03 Date: Wed, 5 Aug 2009 06:07:01 -0700 (PDT) From: IETF I-D Submission Tool To: balazs.lengyel@ericsson.com CC: andy@netconfcentral.com A new version of I-D, draft-ietf-netconf-with-defaults-03.txt has been successfuly submitted by Balazs Lengyel and posted to the IETF repository. Filename: draft-ietf-netconf-with-defaults Revision: 03 Title: With-defaults capability for NETCONF Creation_date: 2009-08-05 WG ID: netconf Number_of_pages: 14 Abstract: The NETCONF protocol defines ways to read configuration data from a NETCONF server. Part of this data is not set by the NETCONF client, but rather a default value is used. In many situations the NETCONF client has a priori knowledge about default data, so the NETCONF server does not need to send it to the client. In other situations the NETCONF manger will need this data as part of the NETCONF messages. This document defines a capability-based extension to the NETCONF protocol that allows the NETCONF client to control whether default values are part of NETCONF messages. The IETF Secretariat. -- Balazs Lengyel Ericsson Hungary Ltd. System Manager ECN: 831 7320 Fax: +36 1 4377792 Tel: +36-1-437-7320 email: Balazs.Lengyel@ericsson.com From root@core3.amsl.com Wed Aug 5 06:15: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 81BFD3A71D9; Wed, 5 Aug 2009 06:15:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20090805131501.81BFD3A71D9@core3.amsl.com> Date: Wed, 5 Aug 2009 06:15:01 -0700 (PDT) Cc: netconf@ietf.org Subject: [Netconf] I-D Action:draft-ietf-netconf-with-defaults-03.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, 05 Aug 2009 13:15: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 : With-defaults capability for NETCONF Author(s) : A. Bierman, B. Lengyel Filename : draft-ietf-netconf-with-defaults-03.txt Pages : 14 Date : 2009-08-05 The NETCONF protocol defines ways to read configuration data from a NETCONF server. Part of this data is not set by the NETCONF client, but rather a default value is used. In many situations the NETCONF client has a priori knowledge about default data, so the NETCONF server does not need to send it to the client. In other situations the NETCONF manger will need this data as part of the NETCONF messages. This document defines a capability-based extension to the NETCONF protocol that allows the NETCONF client to control whether default values are part of NETCONF messages. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-netconf-with-defaults-03.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-with-defaults-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-08-05060701.I-D@ietf.org> --NextPart-- From andy@netconfcentral.com Wed Aug 5 06:22: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 369C73A680B for ; Wed, 5 Aug 2009 06:22:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.498 X-Spam-Level: X-Spam-Status: No, score=-2.498 tagged_above=-999 required=5 tests=[AWL=0.101, 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 K9prSckCdQ+5 for ; Wed, 5 Aug 2009 06:22:19 -0700 (PDT) Received: from n25.bullet.mail.mud.yahoo.com (n25.bullet.mail.mud.yahoo.com [68.142.206.220]) by core3.amsl.com (Postfix) with SMTP id 5620D3A6906 for ; Wed, 5 Aug 2009 06:22:19 -0700 (PDT) Received: from [68.142.200.225] by n25.bullet.mail.mud.yahoo.com with NNFMP; 05 Aug 2009 13:22:20 -0000 Received: from [68.142.201.241] by t6.bullet.mud.yahoo.com with NNFMP; 05 Aug 2009 13:22:20 -0000 Received: from [127.0.0.1] by omp402.mail.mud.yahoo.com with NNFMP; 05 Aug 2009 13:22:20 -0000 X-Yahoo-Newman-Id: 150366.85634.bm@omp402.mail.mud.yahoo.com Received: (qmail 75615 invoked from network); 5 Aug 2009 13:22:19 -0000 Received: from unknown (HELO ?192.168.0.10?) (andy@67.125.157.61 with plain) by smtp105.sbc.mail.sp1.yahoo.com with SMTP; 5 Aug 2009 13:22:19 -0000 X-YMail-OSG: S36_SZEVM1ltO8A_Xtdjt1Z2rBAP_fPBW8S7K0bW7C8MSZrNLaAojK1MmeEn9NNUCSRsSoZyWUKVZY9jnEzu0umjM54ts3sw_B0MQsWC7KB7XYNd9El003yvgoX5Pz.UOLb52yzS5CjmHXYWhoa.p07.aJ8teLXX4OQbATy0SLNaGGFyTbr3Y9tY8Da5cs5wpyweA3STIk36I1DajbyLUFfz_6ehFG4OoavqGyRGWErneuxkaXCv5wcwzG_49Dh1mAOuFI4Kc9c5rLM- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4A79873D.1030007@netconfcentral.com> Date: Wed, 05 Aug 2009 06:21:01 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.22 (X11/20090608) MIME-Version: 1.0 To: WashamFan References: <20090803202203.GA20902@elstar.local> <4A7773BB.1080206@netconfcentral.com> <20090804095639.GA21611@elstar.local> <4A784734.7080201@netconfcentral.com> <20090804144838.GA962@elstar.local> <4A784E8E.8000007@netconfcentral.com> <20090804184136.GC1038@elstar.local> <4A788A66.4030106@bwijnen.net> <20090804211449.GA1307@elstar.local> <4A78AA22.4070405@netconfcentral.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Netconf Subject: Re: [Netconf] Fw: Database Architecture OK or NOT-OK? 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, 05 Aug 2009 13:22:20 -0000 WashamFan wrote: >> Note that the agent MUST send the session-id of the >> lock-holder (lock-denied error-tag), but in this case, >> there is no lock holder. >> >> Is the agent supposed to send session-id=0 in this case? >> That will look like SNMP or CLI has the lock. >> > > session-id makes no sense in above case, since no one has the lock. > I don't think we need session-id field in this case. > You are right: pg 51: If the lock is already held, the element will be 'lock-denied' and the element will include the of the lock owner. Section 7.6 never says what error-tag to send if the lock cannot be granted because the candidate is dirty. Section 8.3.5 should be the place where this is specified, but it isn't. So the situation is even worse than I thought: When the candidate is dirty, an unspecified error that will certainly be implemented differently on every agent is used to identity the problem. > washam > Andy From andy@netconfcentral.com Wed Aug 5 06:27: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 E56D828C577 for ; Wed, 5 Aug 2009 06:27:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.5 X-Spam-Level: X-Spam-Status: No, score=-2.5 tagged_above=-999 required=5 tests=[AWL=0.099, 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 RNKt1qzvLobg for ; Wed, 5 Aug 2009 06:27:56 -0700 (PDT) Received: from smtp112.sbc.mail.mud.yahoo.com (smtp112.sbc.mail.mud.yahoo.com [68.142.198.211]) by core3.amsl.com (Postfix) with SMTP id D15CE28C573 for ; Wed, 5 Aug 2009 06:27:56 -0700 (PDT) Received: (qmail 91568 invoked from network); 5 Aug 2009 13:27:58 -0000 Received: from unknown (HELO ?192.168.0.10?) (andy@67.125.157.61 with plain) by smtp112.sbc.mail.mud.yahoo.com with SMTP; 5 Aug 2009 13:27:57 -0000 X-Yahoo-SMTP: lZEgoqiswBBhrbcScc4Il618oJqVFCyDBDjlTkMv3Go- X-YMail-OSG: v1Xx25MVM1k21BCOpQdEhHk_oBFfzVbgRqnQ8FNW0o_phIOTtxVRphz4ayiEnajlajDO1Zs8LoaCcsS79.ipvruydd.9m6KAalSRQgUy00hlelNBNTB7YAtki1nlVeR8kN5rNYfH.z65YkCMbagwtDLhNWmnCDOHHuNW8Wl.Vhmk8Rj2K0T5ivWEHgvqbE_vnNImes1cD1fBpp61vz3b22zifLAF3QGKvLeRB9bsZ2IWu5oCXdaMSd6gjxLg5aB28F4lTBrqLUQWQHOshOZ_mABb5PE.uZRAa7fL4S7czd8v.aA- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4A79888E.9010105@netconfcentral.com> Date: Wed, 05 Aug 2009 06:26:38 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.22 (X11/20090608) MIME-Version: 1.0 To: Balazs Lengyel References: <4A71D2E9.4080004@netconfcentral.com> <4A79793C.5080502@ericsson.com> In-Reply-To: <4A79793C.5080502@ericsson.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: NETCONF Subject: Re: [Netconf] with-defaults clarification 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, 05 Aug 2009 13:27:58 -0000 Balazs Lengyel wrote: > Hello Andy, > The draft says in chapter 2.5 > " is only affected if the target of the operation is a > URL." OK -- so the agent will use whatever means it wants to decide how to save data to startup. So even if it is officially ignored, that doesn't mean the agent cannot use the value (if it wants) to decide how should be stored. I don't understand why there needs to be a CLR like it MUST be ignored, vs. it MAY be ignored. Can you explain that? Since the agent is free to choose any defaults storage scheme it wants, what its the point of the CLR for in the first place? > Balazs Andy > > Andy Bierman wrote: >> Hi, >> >> I think the with-defaults draft should be clarified to >> indicate that the parameter is ignored >> for if the target of the copy operation >> is the candidate or running databases. >> >> >> Andy >> >> _______________________________________________ >> Netconf mailing list >> Netconf@ietf.org >> https://www.ietf.org/mailman/listinfo/netconf >> > From j.schoenwaelder@jacobs-university.de Wed Aug 5 07:34:43 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 8F5223A6C10 for ; Wed, 5 Aug 2009 07:34:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.212 X-Spam-Level: X-Spam-Status: No, score=-2.212 tagged_above=-999 required=5 tests=[AWL=0.037, 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 tt9fNxmDWDpT for ; Wed, 5 Aug 2009 07:34:42 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id EA1B73A6C24 for ; Wed, 5 Aug 2009 07:34:34 -0700 (PDT) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 8E6F3C006D; Wed, 5 Aug 2009 16:34:37 +0200 (CEST) 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 vDj72BMjnKt7; Wed, 5 Aug 2009 16:34:36 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 7B7E4C006B; Wed, 5 Aug 2009 16:34:36 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 0E60EB79BD0; Wed, 5 Aug 2009 16:34:35 +0200 (CEST) Date: Wed, 5 Aug 2009 16:34:34 +0200 From: Juergen Schoenwaelder To: Andy Bierman Message-ID: <20090805143434.GB2612@elstar.local> Mail-Followup-To: Andy Bierman , WashamFan , Netconf References: <20090804095639.GA21611@elstar.local> <4A784734.7080201@netconfcentral.com> <20090804144838.GA962@elstar.local> <4A784E8E.8000007@netconfcentral.com> <20090804184136.GC1038@elstar.local> <4A788A66.4030106@bwijnen.net> <20090804211449.GA1307@elstar.local> <4A78AA22.4070405@netconfcentral.com> <4A79873D.1030007@netconfcentral.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4A79873D.1030007@netconfcentral.com> User-Agent: Mutt/1.5.19 (2009-01-05) Cc: Netconf Subject: Re: [Netconf] Fw: Database Architecture OK or NOT-OK? 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, 05 Aug 2009 14:34:43 -0000 On Wed, Aug 05, 2009 at 03:21:01PM +0200, Andy Bierman wrote: > WashamFan wrote: > >> Note that the agent MUST send the session-id of the > >> lock-holder (lock-denied error-tag), but in this case, > >> there is no lock holder. > >> > >> Is the agent supposed to send session-id=0 in this case? > >> That will look like SNMP or CLI has the lock. > >> > > > > session-id makes no sense in above case, since no one has the lock. > > I don't think we need session-id field in this case. > > > > You are right: > > pg 51: > > If the lock is already held, the element will be > 'lock-denied' and the element will include the > of the lock owner. > > Section 7.6 never says what error-tag to send > if the lock cannot be granted because the candidate > is dirty. Section 8.3.5 should be the place > where this is specified, but it isn't. > > So the situation is even worse than I thought: > When the candidate is dirty, an unspecified error > that will certainly be implemented differently on every > agent is used to identity the problem. And it is even more unclear what 'no dirty candidate rule' in section 7.5 tries to achieve if you have :writable running if I do this: discard-changes() edit-config('running', bla bla) lock('candidate') Since I did not touch 'candidate', the lock should be granted according to this text: * The target configuration is , it has already been modified, and these changes have not been committed or rolled back. In this case, the content of 'candidate' is not the same as 'running' either and I might be able to construct the very same situation by doing this discard-changes() edit-config('candidate', inverse of bla bla) lock('candidate') and this time the lock fails. Once again, I like to see someone here explain why things were done in this way. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From Tomasz.Mikolajczyk@s3group.com Wed Aug 5 08:01: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 09BF628C4F2 for ; Wed, 5 Aug 2009 08:01:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.486 X-Spam-Level: X-Spam-Status: No, score=0.486 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_PL=1.135, HOST_EQ_PL=1.95] 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 8J2sfisz+ZKV for ; Wed, 5 Aug 2009 08:01:00 -0700 (PDT) Received: from ormo.s3group.com.pl (ormo.s3group.com.pl [212.160.116.194]) by core3.amsl.com (Postfix) with ESMTP id C02A728C45B for ; Wed, 5 Aug 2009 08:00:59 -0700 (PDT) Received: from exwro.wroclaw.ad.s3group.com (exwro.wroclaw.s3group.com [192.168.88.33]) by ormo.s3group.com.pl with ESMTP id n75F0jeE008616; Wed, 5 Aug 2009 17:00:45 +0200 Received: from [192.168.88.87] ([192.168.88.87]) by exwro.wroclaw.ad.s3group.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 5 Aug 2009 17:00:44 +0200 Message-ID: <4A799E9D.4050605@s3group.com> Date: Wed, 05 Aug 2009 17:00:45 +0200 From: Tomasz Mikolajczyk Organization: Silicon & Software Systems User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Andy Bierman , WashamFan , Netconf References: <20090804095639.GA21611@elstar.local> <4A784734.7080201@netconfcentral.com> <20090804144838.GA962@elstar.local> <4A784E8E.8000007@netconfcentral.com> <20090804184136.GC1038@elstar.local> <4A788A66.4030106@bwijnen.net> <20090804211449.GA1307@elstar.local> <4A78AA22.4070405@netconfcentral.com> <4A79873D.1030007@netconfcentral.com> <20090805143434.GB2612@elstar.local> In-Reply-To: <20090805143434.GB2612@elstar.local> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 05 Aug 2009 15:00:44.0948 (UTC) FILETIME=[822DDD40:01CA15DD] X-Scanner: InterScan AntiVirus for Sendmail X-Filter-Version: 1.11,S3-1.6 (ormo.s3group.com.pl) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.0 (ormo.s3group.com.pl [212.160.116.194]); Wed, 05 Aug 2009 17:00:48 +0200 (CEST) Subject: Re: [Netconf] Fw: Database Architecture OK or NOT-OK? 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, 05 Aug 2009 15:01:01 -0000 Hi, I brought this lock issue up over a half year ago. Here is that thread: http://www.ietf.org/mail-archive/web/netconf/current/msg03992.html Regards, Tomasz Mikolajczyk Juergen Schoenwaelder wrote: > On Wed, Aug 05, 2009 at 03:21:01PM +0200, Andy Bierman wrote: >> WashamFan wrote: >>>> Note that the agent MUST send the session-id of the >>>> lock-holder (lock-denied error-tag), but in this case, >>>> there is no lock holder. >>>> >>>> Is the agent supposed to send session-id=0 in this case? >>>> That will look like SNMP or CLI has the lock. >>>> >>> session-id makes no sense in above case, since no one has the lock. >>> I don't think we need session-id field in this case. >>> >> You are right: >> >> pg 51: >> >> If the lock is already held, the element will be >> 'lock-denied' and the element will include the >> of the lock owner. >> >> Section 7.6 never says what error-tag to send >> if the lock cannot be granted because the candidate >> is dirty. Section 8.3.5 should be the place >> where this is specified, but it isn't. >> >> So the situation is even worse than I thought: >> When the candidate is dirty, an unspecified error >> that will certainly be implemented differently on every >> agent is used to identity the problem. > > And it is even more unclear what 'no dirty candidate rule' in section > 7.5 tries to achieve if you have :writable running if I do this: > > discard-changes() > edit-config('running', bla bla) > lock('candidate') > > Since I did not touch 'candidate', the lock should be granted > according to this text: > > * The target configuration is , it has already been > modified, and these changes have not been committed or rolled > back. > > In this case, the content of 'candidate' is not the same as 'running' > either and I might be able to construct the very same situation by > doing this > > discard-changes() > edit-config('candidate', inverse of bla bla) > lock('candidate') > > and this time the lock fails. Once again, I like to see someone here > explain why things were done in this way. > > /js > The information contained in this e-mail and in any attachments is confidential and is designated solely for the attention of the intended recipient(s). If you are not an intended recipient, you must not use, disclose, copy, distribute or retain this e-mail or any part thereof. If you have received this e-mail in error, please notify the sender by return e-mail and delete all copies of this e-mail from your computer system(s). Please direct any additional queries to: communications@s3group.com. Thank You. Silicon and Software Systems Limited. Registered in Ireland no. 378073. Registered Office: South County Business Park, Leopardstown, Dublin 18 From andy@netconfcentral.com Wed Aug 5 08:09: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 47C5628C0F2 for ; Wed, 5 Aug 2009 08:09:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.502 X-Spam-Level: X-Spam-Status: No, score=-2.502 tagged_above=-999 required=5 tests=[AWL=0.097, 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 R530N5tvsBKy for ; Wed, 5 Aug 2009 08:09:40 -0700 (PDT) Received: from smtp107.sbc.mail.mud.yahoo.com (smtp107.sbc.mail.mud.yahoo.com [68.142.198.206]) by core3.amsl.com (Postfix) with SMTP id 9EF7F28C5AF for ; Wed, 5 Aug 2009 08:09:20 -0700 (PDT) Received: (qmail 89400 invoked from network); 5 Aug 2009 15:09:16 -0000 Received: from unknown (HELO ?192.168.0.10?) (andy@67.125.157.61 with plain) by smtp107.sbc.mail.mud.yahoo.com with SMTP; 5 Aug 2009 15:09:16 -0000 X-YMail-OSG: K1GBMa8VM1mqKEEyjCSX2SsiKR37HB1rD5l2PNTRYdxt3cBu._Gll6aqp3JIWe9oXh1Qw08oDqpJezqpd.4yc.4sVgZWD6ueq7tHkqxJed0xx5G14uGwiYYQgaOu5xkoWFafp8xTljusnCQh1JgCGfEmwPopW9dZ543s_49q56n7qkU56_DxbBAq12m7lMtefNTP7ZsKvMU50WIooQcenr76BUgU8WfjH_oFJZ3cW_ny7uGSWM_heu0N0BN8eHOK1hQ8XX_EUvu1SUdVSKnA_RGlOkqxcz3oAUrvI.S0K8x6qn35tEE- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4A79A0C9.3070205@netconfcentral.com> Date: Wed, 05 Aug 2009 08:10:01 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.22 (X11/20090608) MIME-Version: 1.0 To: Andy Bierman , WashamFan , Netconf References: <20090804095639.GA21611@elstar.local> <4A784734.7080201@netconfcentral.com> <20090804144838.GA962@elstar.local> <4A784E8E.8000007@netconfcentral.com> <20090804184136.GC1038@elstar.local> <4A788A66.4030106@bwijnen.net> <20090804211449.GA1307@elstar.local> <4A78AA22.4070405@netconfcentral.com> <4A79873D.1030007@netconfcentral.com> <20090805143434.GB2612@elstar.local> In-Reply-To: <20090805143434.GB2612@elstar.local> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [Netconf] Fw: Database Architecture OK or NOT-OK? 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, 05 Aug 2009 15:09:41 -0000 Juergen Schoenwaelder wrote: > On Wed, Aug 05, 2009 at 03:21:01PM +0200, Andy Bierman wrote: >> WashamFan wrote: >>>> Note that the agent MUST send the session-id of the >>>> lock-holder (lock-denied error-tag), but in this case, >>>> there is no lock holder. >>>> >>>> Is the agent supposed to send session-id=0 in this case? >>>> That will look like SNMP or CLI has the lock. >>>> >>> session-id makes no sense in above case, since no one has the lock. >>> I don't think we need session-id field in this case. >>> >> You are right: >> >> pg 51: >> >> If the lock is already held, the element will be >> 'lock-denied' and the element will include the >> of the lock owner. >> >> Section 7.6 never says what error-tag to send >> if the lock cannot be granted because the candidate >> is dirty. Section 8.3.5 should be the place >> where this is specified, but it isn't. >> >> So the situation is even worse than I thought: >> When the candidate is dirty, an unspecified error >> that will certainly be implemented differently on every >> agent is used to identity the problem. > > And it is even more unclear what 'no dirty candidate rule' in section > 7.5 tries to achieve if you have :writable running if I do this: > > discard-changes() > edit-config('running', bla bla) > lock('candidate') > > Since I did not touch 'candidate', the lock should be granted s/should/should not/ > according to this text: > > * The target configuration is , it has already been > modified, and these changes have not been committed or rolled > back. > > In this case, the content of 'candidate' is not the same as 'running' > either and I might be able to construct the very same situation by > doing this > > discard-changes() > edit-config('candidate', inverse of bla bla) > lock('candidate') > > and this time the lock fails. Once again, I like to see someone here > explain why things were done in this way. > indeed. I just changed my code to comply with this CLR. I would rather lose the CLR. For the dirty-lock error, let's spin the wheel (in-use, resource-denied, operation-failed...) how about resource-denied, since in-use is for a write-op to a locked database? (I need to update the issue tracker anyway...) > /js > Andy From mehmet.ersue@nsn.com Wed Aug 5 08:53: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 38F5328C491 for ; Wed, 5 Aug 2009 08:53:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.232 X-Spam-Level: X-Spam-Status: No, score=-5.232 tagged_above=-999 required=5 tests=[AWL=1.367, 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 GetmdSONtzvi for ; Wed, 5 Aug 2009 08:53:20 -0700 (PDT) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [217.115.75.233]) by core3.amsl.com (Postfix) with ESMTP id 0656328C3DC for ; Wed, 5 Aug 2009 08:53:19 -0700 (PDT) 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 n75FrL4c016740 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Wed, 5 Aug 2009 17:53:21 +0200 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 n75FrLNu014080 for ; Wed, 5 Aug 2009 17:53:21 +0200 Received: from DEMUEXC005.nsn-intra.net ([10.150.128.17]) by demuexc024.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 5 Aug 2009 17:53:20 +0200 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, 5 Aug 2009 17:53:19 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Code license statements WAS:FW: DISCUSS: draft-ietf-netconf-partial-lock Thread-Index: AcoV2oRHumrSPr7HQUW73uHCG4JGNAABEXDQAADZaTA= From: "Ersue, Mehmet (NSN - DE/Munich)" To: X-OriginalArrivalTime: 05 Aug 2009 15:53:20.0542 (UTC) FILETIME=[DB0F4BE0:01CA15E4] Subject: [Netconf] Code license statements WAS:FW: DISCUSS: draft-ietf-netconf-partial-lock 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, 05 Aug 2009 15:53:21 -0000 > Romascanu, Dan (Dan) wrote: ... > > As far as I know the agreement in the IESG is to add a note to the RFC=20 > > Editor pointing to the pieces of code that would need license=20 > > fragments and instructing the Editor to add these according to the=20 > > most update set of rules at the date of the publication (which may or=20 > > may not be the final one, according to the timing of the approvals). I think the issue is also relevant for other NETCONF I-Ds. I-D authors should consider to prepare for publishing=20 of code following the statement: "any text found between the markers and=20 , or otherwise clearly labeled as a Code=20 Component, shall be considered a "Code Component"." It might be also interesting to consume the policy=20 and procedures page: http://trustee.ietf.org/policyandprocedures.html Mehmet -----Original Message----- From: ext Romascanu, Dan (Dan) [mailto:dromasca@avaya.com]=20 Sent: Wednesday, August 05, 2009 5:18 PM To: Balazs Lengyel Cc: Adrian Farrel; iesg@ietf.org; netconf-chairs@tools.ietf.org; draft-ietf-netconf-partial-lock@tools.ietf.org; Martin Bjorklund Subject: RE: DISCUSS: draft-ietf-netconf-partial-lock Balazs, You can get the current information from links accessible at http://trustee.ietf.org/license-info/ . This is however now discussed and last called again, so some details may change. This is why we are providing a partial approval at the IESG level, and ask the RFC Editor to insert the best text at the time of the publication. Of course all is run again for approval with the editors and the AD's at that time.=20 Right now it is up to Adrian to agree on the solution, as he is holding the DISCUSS on this issue.=20 Dan > -----Original Message----- > From: Balazs Lengyel [mailto:balazs.lengyel@ericsson.com]=20 > Sent: Wednesday, August 05, 2009 5:39 PM > To: Romascanu, Dan (Dan) > Cc: Adrian Farrel; iesg@ietf.org;=20 > netconf-chairs@tools.ietf.org;=20 > draft-ietf-netconf-partial-lock@tools.ietf.org; Martin Bjorklund > Subject: Re: DISCUSS: draft-ietf-netconf-partial-lock >=20 > Hello Dan, > This is OK for me. Is this the final decision? Are there any=20 > examples of the text for the editor? > Balazs >=20 > Romascanu, Dan (Dan) wrote: > > Adrian, > >=20 > > As far as I know the agreement in the IESG is to add a note=20 > to the RFC=20 > > Editor pointing to the pieces of code that would need license=20 > > fragments and instructing the Editor to add these according to the=20 > > most update set of rules at the date of the publication=20 > (which may or=20 > > may not be the final one, according to the timing of the approvals). > >=20 > > Would that work for you in this case?=20 > >=20 > > Dan > > =20 > >=20 > >> -----Original Message----- > >> From: Balazs Lengyel [mailto:balazs.lengyel@ericsson.com] > >> Sent: Wednesday, August 05, 2009 1:51 PM > >> To: Adrian Farrel > >> Cc: iesg@ietf.org; netconf-chairs@tools.ietf.org;=20 > >> draft-ietf-netconf-partial-lock@tools.ietf.org; Romascanu,=20 > Dan (Dan);=20 > >> Martin Bjorklund > >> Subject: Re: DISCUSS: draft-ietf-netconf-partial-lock > >> > >> Hello Dan, > >> Please have a look at Adrian's comment. I don't know the correct=20 > >> answer. Can you please help me. > >> If needed I will put in the license statements, but are=20 > they needed.=20 > >> (If needed please point me to the correct statements!) Balazs > >> > >> Adrian Farrel wrote: > >>> =3D=3D=3D > >>> > >>> I think that the XML examples in 2.4.1.1 etc., schema in > >> Appendix A, > >>> and YANG in Appendix B qualify for code license statements. > >>> > >> --=20 > >> Balazs Lengyel Ericsson Hungary Ltd. > >> System Manager > >> ECN: 831 7320 Fax: +36 1 4377792 > >> Tel: +36-1-437-7320 email:=20 > >> Balazs.Lengyel@ericsson.com > >> >=20 > --=20 > Balazs Lengyel Ericsson Hungary Ltd. > System Manager > ECN: 831 7320 Fax: +36 1 4377792 > Tel: +36-1-437-7320 email:=20 > Balazs.Lengyel@ericsson.com >=20 From mark@ellisonsoftware.com Wed Aug 5 12:00: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 0D0A228C631 for ; Wed, 5 Aug 2009 12:00:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.677 X-Spam-Level: X-Spam-Status: No, score=-101.677 tagged_above=-999 required=5 tests=[AWL=-0.299, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_34=0.6, 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 wlQBwEkx61fN for ; Wed, 5 Aug 2009 12:00:09 -0700 (PDT) Received: from mail-yx0-f173.google.com (mail-yx0-f173.google.com [209.85.210.173]) by core3.amsl.com (Postfix) with ESMTP id AC94B3A6C4C for ; Wed, 5 Aug 2009 11:58:35 -0700 (PDT) Received: by yxe3 with SMTP id 3so439202yxe.29 for ; Wed, 05 Aug 2009 11:58:36 -0700 (PDT) MIME-Version: 1.0 Sender: mark@ellisonsoftware.com Received: by 10.151.15.2 with SMTP id s2mr16219010ybi.213.1249498716281; Wed, 05 Aug 2009 11:58:36 -0700 (PDT) Date: Wed, 5 Aug 2009 14:58:36 -0400 X-Google-Sender-Auth: c509b4260459df22 Message-ID: <8a0268750908051158m2658292ctaf2a14cbd0206c39@mail.gmail.com> From: Mark Ellison To: netconf@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: [Netconf] Question on text constraints within for NETCONF protocol level errors 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, 05 Aug 2009 19:00:11 -0000 Hi, I am working from RFC4741/draft-4741bis-00 to develop a compliant NETCONF implementation and have a question with respect to the element in . The element is described in section 4.3. as: =A0=A0=A0=A0 "Contains a string suitable for human display that =A0=A0=A0=A0=A0 describes the error condition.=A0 This element will not be = present =A0=A0=A0=A0=A0 if no appropriate message is provided for a particular erro= r =A0=A0=A0=A0=A0 condition.=A0 This element SHOULD include an xml:lang attri= bute as =A0=A0=A0=A0=A0 defined in [1] and discussed in [12]." And just before the examples in this section the following statement appear= s: =A0=A0=A0=A0 "Appendix A enumerates the standard NETCONF errors." If my NETCONF client sends a frame containing NETCONF protocol level errors as follow: =A0=A0=A0 =A0=A0=A0=A0=A0=A0=A0 =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 =A0=A0=A0=A0=A0=A0=A0 =A0=A0=A0=A0=A0=A0=A0 splurge =A0=A0=A0=A0=A0=A0=A0 set-then-test =A0=A0=A0=A0=A0=A0=A0 contemplate-on-error =A0=A0=A0=A0=A0=A0=A0 =A0=A0=A0=A0=A0=A0=A0 =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 blah blah blah blah =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 =A0=A0=A0=A0=A0=A0=A0 =A0=A0=A0 ]]>]]> If my NETCONF server is constrained by Appendix A, then it will respond with: (example reply 1) =A0=A0=A0 =A0=A0=A0=A0=A0=A0=A0 rpc =A0=A0=A0=A0=A0=A0=A0 bad-element =A0=A0=A0=A0=A0=A0=A0 error =A0=A0=A0=A0=A0=A0=A0 An element value is no= t correct; e.g., wrong type, out of range, pattern mismatch. =A0=A0=A0=A0=A0=A0=A0 =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 default-operation =A0=A0=A0=A0=A0=A0=A0 =A0=A0=A0 =A0=A0=A0 =A0=A0=A0=A0=A0=A0=A0 rpc =A0=A0=A0=A0=A0=A0=A0 bad-element =A0=A0=A0=A0=A0=A0=A0 error =A0=A0=A0=A0=A0=A0=A0 An element value is no= t correct; e.g., wrong type, out of range, pattern mismatch. =A0=A0=A0=A0=A0=A0=A0 =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 test-option =A0=A0=A0=A0=A0=A0=A0 =A0=A0=A0 =A0=A0=A0 =A0=A0=A0=A0=A0=A0=A0 rpc =A0=A0=A0=A0=A0=A0=A0 bad-element =A0=A0=A0=A0=A0=A0=A0 error =A0=A0=A0=A0=A0=A0=A0 An element value is no= t correct; e.g., wrong type, out of range, pattern mismatch. =A0=A0=A0=A0=A0=A0=A0 =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 error-option =A0=A0=A0=A0=A0=A0=A0 =A0=A0=A0 =A0=A0=A0 =A0=A0=A0=A0=A0=A0=A0 rpc =A0=A0=A0=A0=A0=A0=A0 unknown-element =A0=A0=A0=A0=A0=A0=A0 error =A0=A0=A0=A0=A0=A0=A0 An unexpected element = is present. =A0=A0=A0=A0=A0=A0=A0 =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 mishigas =A0=A0=A0=A0=A0=A0=A0 =A0=A0=A0 ]]>]]> However, there is more specific information available that my NETCONF server can provide with respect to the simple types having an enumeration constraint- , and : (example reply 2) =A0=A0=A0 =A0=A0=A0=A0=A0=A0=A0 rpc =A0=A0=A0=A0=A0=A0=A0 bad-element =A0=A0=A0=A0=A0=A0=A0 error =A0=A0=A0=A0=A0=A0=A0 Value 'splurge' is not facet-valid with respect to enumeration '[merge, replace, none]'. It must be a value from the enumeration. =A0=A0=A0=A0=A0=A0=A0 =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 default-operation =A0=A0=A0=A0=A0=A0=A0 =A0=A0=A0 =A0=A0=A0 =A0=A0=A0=A0=A0=A0=A0 rpc =A0=A0=A0=A0=A0=A0=A0 bad-element =A0=A0=A0=A0=A0=A0=A0 error =A0=A0=A0=A0=A0=A0=A0 Value 'set-then-test' = is not facet-valid with respect to enumeration '[test-then-set, set]'. It must be a value from the enumeration. =A0=A0=A0=A0=A0=A0=A0 =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 test-option =A0=A0=A0=A0=A0=A0=A0 =A0=A0=A0 =A0=A0=A0 =A0=A0=A0=A0=A0=A0=A0 rpc =A0=A0=A0=A0=A0=A0=A0 bad-element =A0=A0=A0=A0=A0=A0=A0 error =A0=A0=A0=A0=A0=A0=A0 Value 'contemplate-on-= error' is not facet-valid with respect to enumeration '[stop-on-error, continue-on-error, rollback-on-error]'. It must be a value from the enumeration. =A0=A0=A0=A0=A0=A0=A0 =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 error-option =A0=A0=A0=A0=A0=A0=A0 =A0=A0=A0 =A0=A0=A0 =A0=A0=A0=A0=A0=A0=A0 rpc =A0=A0=A0=A0=A0=A0=A0 unknown-element =A0=A0=A0=A0=A0=A0=A0 error =A0=A0=A0=A0=A0=A0=A0 An unexpected element = is present. =A0=A0=A0=A0=A0=A0=A0 =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 mishigas =A0=A0=A0=A0=A0=A0=A0 =A0=A0=A0 ]]>]]> The above error-message text is taken directly from the SAX/DOM parser errors based upon the NETCONF schema and appear to be more useful than the error-message text contained in Appendix A. Now, in order to be compliant wih respect to 4741/4741bis does my NETCONF server for errors occurring at the NETCONF protocol level need to constrain eror-message text to that contained in Appendix A?=A0 Or, can the error-message text be as in example reply 2?=A0 (Or even a concatenation of Appendix A error-message text with the text in example reply 2?) Regards, Mark From j.schoenwaelder@jacobs-university.de Wed Aug 5 13:51: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 B9CD03A6A0E for ; Wed, 5 Aug 2009 13:51:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.213 X-Spam-Level: X-Spam-Status: No, score=-2.213 tagged_above=-999 required=5 tests=[AWL=0.036, 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 b8KG4O-qSJx5 for ; Wed, 5 Aug 2009 13:51:02 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id BC8DA3A6908 for ; Wed, 5 Aug 2009 13:51:02 -0700 (PDT) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 1B53FC0011; Wed, 5 Aug 2009 22:51:05 +0200 (CEST) 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 8kj837L3JKCF; Wed, 5 Aug 2009 22:50:42 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 63F52C002E; Wed, 5 Aug 2009 22:50:42 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 54B01B79FAD; Wed, 5 Aug 2009 22:50:41 +0200 (CEST) Date: Wed, 5 Aug 2009 22:50:41 +0200 From: Juergen Schoenwaelder To: Mark Ellison Message-ID: <20090805205041.GA2864@elstar.local> Mail-Followup-To: Mark Ellison , "netconf@ietf.org" References: <8a0268750908051158m2658292ctaf2a14cbd0206c39@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <8a0268750908051158m2658292ctaf2a14cbd0206c39@mail.gmail.com> User-Agent: Mutt/1.5.19 (2009-01-05) Cc: "netconf@ietf.org" Subject: Re: [Netconf] Question on text constraints within for NETCONF protocol level errors 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, 05 Aug 2009 20:51:03 -0000 On Wed, Aug 05, 2009 at 08:58:36PM +0200, Mark Ellison wrote: [...] > Now, in order to be compliant wih respect to 4741/4741bis does my > NETCONF server for errors occurring at the NETCONF protocol level need > to constrain eror-message text to that contained in Appendix A?? Or, > can the error-message text be as in example reply 2?? (Or even a > concatenation of Appendix A error-message text with the text in > example reply 2?) My understanding is that the error-message text is implementation specific and for consumption by human beings while programs use the more formalized error fields. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From j.schoenwaelder@jacobs-university.de Wed Aug 5 14:03:34 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 296793A7232 for ; Wed, 5 Aug 2009 14:03:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.214 X-Spam-Level: X-Spam-Status: No, score=-2.214 tagged_above=-999 required=5 tests=[AWL=0.035, 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 cSdM8ftpfiwK for ; Wed, 5 Aug 2009 14:03:33 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 370ED3A722E for ; Wed, 5 Aug 2009 14:03:33 -0700 (PDT) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id DB19CC002E; Wed, 5 Aug 2009 23:03:35 +0200 (CEST) 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 xziW9DjEKN6x; Wed, 5 Aug 2009 23:03:35 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id DE903C0011; Wed, 5 Aug 2009 23:03:34 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 72DF9B7A06D; Wed, 5 Aug 2009 23:03:33 +0200 (CEST) Date: Wed, 5 Aug 2009 23:03:33 +0200 From: Juergen Schoenwaelder To: Tomasz Mikolajczyk Message-ID: <20090805210333.GC2864@elstar.local> Mail-Followup-To: Tomasz Mikolajczyk , Andy Bierman , WashamFan , Netconf References: <20090804144838.GA962@elstar.local> <4A784E8E.8000007@netconfcentral.com> <20090804184136.GC1038@elstar.local> <4A788A66.4030106@bwijnen.net> <20090804211449.GA1307@elstar.local> <4A78AA22.4070405@netconfcentral.com> <4A79873D.1030007@netconfcentral.com> <20090805143434.GB2612@elstar.local> <4A799E9D.4050605@s3group.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4A799E9D.4050605@s3group.com> User-Agent: Mutt/1.5.19 (2009-01-05) Cc: Netconf Subject: Re: [Netconf] Fw: Database Architecture OK or NOT-OK? 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, 05 Aug 2009 21:03:34 -0000 On Wed, Aug 05, 2009 at 05:00:45PM +0200, Tomasz Mikolajczyk wrote: > I brought this lock issue up over a half year ago. Here is that thread: > http://www.ietf.org/mail-archive/web/netconf/current/msg03992.html Thanks for the pointer. It would really be nice to have an explanation why the current behaviour is there and useful. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From j.schoenwaelder@jacobs-university.de Thu Aug 6 04:13: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 1648F3A6ADF for ; Thu, 6 Aug 2009 04:13:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.914 X-Spam-Level: X-Spam-Status: No, score=-1.914 tagged_above=-999 required=5 tests=[AWL=-0.265, BAYES_00=-2.599, HELO_EQ_DE=0.35, J_CHICKENPOX_210=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 aegHUixF6Vfb for ; Thu, 6 Aug 2009 04:13:06 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 0D8173A6805 for ; Thu, 6 Aug 2009 04:13:06 -0700 (PDT) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 9FB63C0079; Thu, 6 Aug 2009 13:13:08 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius4.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id enFP5CzJA-Vc; Thu, 6 Aug 2009 13:13:07 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id ED358C0077; Thu, 6 Aug 2009 13:13:06 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id C9B40B7A6DE; Thu, 6 Aug 2009 13:13:05 +0200 (CEST) Date: Thu, 6 Aug 2009 13:13:05 +0200 From: Juergen Schoenwaelder To: Balazs Lengyel Message-ID: <20090806111305.GA3340@elstar.local> Mail-Followup-To: Balazs Lengyel , netconf mailing list References: <4A7984EA.4000703@ericsson.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4A7984EA.4000703@ericsson.com> User-Agent: Mutt/1.5.19 (2009-01-05) Cc: netconf mailing list Subject: Re: [Netconf] [Fwd: New Version Notification for draft-ietf-netconf-with-defaults-03] 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: Thu, 06 Aug 2009 11:13:07 -0000 On Wed, Aug 05, 2009 at 03:11:06PM +0200, Balazs Lengyel wrote: > Sorry for doing this in the middle of WG Last call, but I posted a > new draft. I realized that it would be important to include the > non-normative YAM in the WG last call. Here is my review of the -03 version of this document. The comments are in document order. s /often needs a single/needs a single/ The text talks about "controls whether default data is part of NETCONF messages"; I would prefer if the text would say that it "extends the NETCONF , , and operations with an additional parameter that allows the NETCONF client to control whether default data is returned in the result. I think we should take the layered architecture of NETCONF serious. This change affects several places of the document since it should nowhere talk about messages. I am not sure how we deal with capabilities within YANG. What about having the ietf-netconf.yang introduce a nc:capability extension statement that can be used to define the capability URI for a YANG feature, just of usage to describe NETCONF protocol extensions? I am thinking of extension nc:capability { description "This extension is used to define capability URIs in NETCONF protocol modules written in YANG. It is not supposed to be used outside of NETCONF protocol specifications."; argument "uri"; } This way, the features used to define protocol capabilities could indicate the capability URI associated with a protocol "feature". I also note that the with-defaults ID adds special parameters to the capability URI which is something we do not have special support for in YANG - think the YANG approach would be to define feature and to use the feature announcement mechanism. Why do we do something special here? I suggest to get rid of the subsubsection headlines 1.1.1 and 1.1.2; just have a section 1.1. s/A NETCONF servers/A NETCONF server/ s/parameter Possible/parameter. Possible/ s/return default data in the NETCONF message/return default data/ In section 2.5, be explicit which error is returned if a client sends a with-default value the server does not support. In the YANG module s/with-defaults-mode-type/with-defaults-mode/ and I would probably have choosen the prefix nc-wd instead of nwd. I would prefer if this document would move along with RFC4741bis so that we can make the YANG normative. /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 Thu Aug 6 08:00: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 3784A3A6E15 for ; Thu, 6 Aug 2009 08:00:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.741 X-Spam-Level: X-Spam-Status: No, score=-1.741 tagged_above=-999 required=5 tests=[AWL=-0.676, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_210=0.6, J_CHICKENPOX_81=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 BL9t+IvRRp8z for ; Thu, 6 Aug 2009 08:00:23 -0700 (PDT) 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 052803A6853 for ; Thu, 6 Aug 2009 08:00:19 -0700 (PDT) Received: (qmail 37835 invoked from network); 6 Aug 2009 15:00:19 -0000 Received: from unknown (HELO ?192.168.0.10?) (andy@67.125.157.61 with plain) by smtp128.sbc.mail.sp1.yahoo.com with SMTP; 6 Aug 2009 15:00:19 -0000 X-YMail-OSG: uCa4h24VM1kGYR8ioHeGad1ZYDOgbbhxDdYUA9lBx4PoroQVZvUIeXnLVJdl1zKOdo99e2nLHsIg.PrOzmCAkjOGrP1LP1dLJteJg1bAk9awYUx4muvj93u.0Kea2iMSpjXzGeElt1VMQa0Bgg8hyQyB3CdhNPV932TfKqXp5m9FZi.cA4DsFkMw.Gnpxl22.hgC8XAFVj5OqNWPp4yGX44dHUk0wcOuLIM2KnBen5lKTCxOIiIg4tKS6M1CPsuHGjbq15Gjxs6ehR1BX.t.HhGDnPZGKdNchm23XyOydFJPtpN7OuA- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4A7AF036.30400@netconfcentral.com> Date: Thu, 06 Aug 2009 08:01:10 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.22 (X11/20090608) MIME-Version: 1.0 To: Balazs Lengyel , netconf mailing list References: <4A7984EA.4000703@ericsson.com> <20090806111305.GA3340@elstar.local> In-Reply-To: <20090806111305.GA3340@elstar.local> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [Netconf] [Fwd: New Version Notification for draft-ietf-netconf-with-defaults-03] 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, 06 Aug 2009 15:00:24 -0000 Juergen Schoenwaelder wrote: > On Wed, Aug 05, 2009 at 03:11:06PM +0200, Balazs Lengyel wrote: > >> Sorry for doing this in the middle of WG Last call, but I posted a >> new draft. I realized that it would be important to include the >> non-normative YAM in the WG last call. > > Here is my review of the -03 version of this document. The comments > are in document order. > > s /often needs a single/needs a single/ > > The text talks about "controls whether default data is part of NETCONF > messages"; I would prefer if the text would say that it > "extends the NETCONF , , and operations > with an additional parameter that allows the NETCONF client to control > whether default data is returned in the result. I think we should take > the layered architecture of NETCONF serious. This change affects > several places of the document since it should nowhere talk about > messages. > > I am not sure how we deal with capabilities within YANG. What about > having the ietf-netconf.yang introduce a nc:capability extension > statement that can be used to define the capability URI for a YANG > feature, just of usage to describe NETCONF protocol extensions? I > am thinking of > > extension nc:capability { > description > "This extension is used to define capability URIs in NETCONF > protocol modules written in YANG. It is not supposed to be > used outside of NETCONF protocol specifications."; > argument "uri"; > } > I am strongly opposed to using extensions to add standard mechanisms to the YANG language. The capability-stmt has been brought up many times before and rejected every time. YANG does not care about NETCONF capabilities. It is a short-sighted, and architecturally immature decision, but it is the NETMOD WG decision. So all NETCONF capabilities need to be defined as YANG features instead. > This way, the features used to define protocol capabilities could > indicate the capability URI associated with a protocol "feature". I > also note that the with-defaults ID adds special parameters to the > capability URI which is something we do not have special support for > in YANG - think the YANG approach would be to define feature and to > use the feature announcement mechanism. Why do we do something special > here? > If this is part of YANG, it needs to be done with normal language constructs. This proposal does not seem to mesh at all with the YANG module capability URI encoding. Why do we need a separate URI for these capabilities? Just advertise the module-uri with features=a,b,c at the end, and it serves the same purpose. Why separate the feature 'a' out into its own capability URI? ... > /js > Andy From j.schoenwaelder@jacobs-university.de Thu Aug 6 08:18:34 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 237FD28C142 for ; Thu, 6 Aug 2009 08:18:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.611 X-Spam-Level: X-Spam-Status: No, score=-1.611 tagged_above=-999 required=5 tests=[AWL=-0.562, BAYES_00=-2.599, HELO_EQ_DE=0.35, J_CHICKENPOX_210=0.6, J_CHICKENPOX_81=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 zetQiLZHmTBb for ; Thu, 6 Aug 2009 08:18:33 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id C1DA43A6C60 for ; Thu, 6 Aug 2009 08:18:32 -0700 (PDT) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 89D61C007B; Thu, 6 Aug 2009 17:18:35 +0200 (CEST) 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 Qxl0qstJXsj6; Thu, 6 Aug 2009 17:18:34 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id A78C6C0082; Thu, 6 Aug 2009 17:18:33 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 5322FB7D1F0; Thu, 6 Aug 2009 17:18:32 +0200 (CEST) Date: Thu, 6 Aug 2009 17:18:32 +0200 From: Juergen Schoenwaelder To: Andy Bierman Message-ID: <20090806151832.GA1013@elstar.local> Mail-Followup-To: Andy Bierman , Balazs Lengyel , netconf mailing list References: <4A7984EA.4000703@ericsson.com> <20090806111305.GA3340@elstar.local> <4A7AF036.30400@netconfcentral.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4A7AF036.30400@netconfcentral.com> User-Agent: Mutt/1.5.19 (2009-01-05) Cc: netconf mailing list Subject: Re: [Netconf] [Fwd: New Version Notification for draft-ietf-netconf-with-defaults-03] 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: Thu, 06 Aug 2009 15:18:34 -0000 On Thu, Aug 06, 2009 at 05:01:10PM +0200, Andy Bierman wrote: > Juergen Schoenwaelder wrote: > > On Wed, Aug 05, 2009 at 03:11:06PM +0200, Balazs Lengyel wrote: > > > >> Sorry for doing this in the middle of WG Last call, but I posted a > >> new draft. I realized that it would be important to include the > >> non-normative YAM in the WG last call. > > > > Here is my review of the -03 version of this document. The comments > > are in document order. > > > > s /often needs a single/needs a single/ > > > > The text talks about "controls whether default data is part of NETCONF > > messages"; I would prefer if the text would say that it > > "extends the NETCONF , , and operations > > with an additional parameter that allows the NETCONF client to control > > whether default data is returned in the result. I think we should take > > the layered architecture of NETCONF serious. This change affects > > several places of the document since it should nowhere talk about > > messages. > > > > I am not sure how we deal with capabilities within YANG. What about > > having the ietf-netconf.yang introduce a nc:capability extension > > statement that can be used to define the capability URI for a YANG > > feature, just of usage to describe NETCONF protocol extensions? I > > am thinking of > > > > extension nc:capability { > > description > > "This extension is used to define capability URIs in NETCONF > > protocol modules written in YANG. It is not supposed to be > > used outside of NETCONF protocol specifications."; > > argument "uri"; > > } > > > > > I am strongly opposed to using extensions to add standard > mechanisms to the YANG language. The capability-stmt has > been brought up many times before and rejected every time. > > YANG does not care about NETCONF capabilities. > It is a short-sighted, and architecturally immature > decision, but it is the NETMOD WG decision. > > So all NETCONF capabilities need to be defined as YANG features > instead. > > > > This way, the features used to define protocol capabilities could > > indicate the capability URI associated with a protocol "feature". I > > also note that the with-defaults ID adds special parameters to the > > capability URI which is something we do not have special support for > > in YANG - think the YANG approach would be to define feature and to > > use the feature announcement mechanism. Why do we do something special > > here? > > > > If this is part of YANG, it needs to be done with normal > language constructs. This proposal does not seem to mesh > at all with the YANG module capability URI encoding. > Why do we need a separate URI for these capabilities? > Just advertise the module-uri with features=a,b,c at the end, > and it serves the same purpose. Why separate the feature 'a' > out into its own capability URI? All I tried to do was to propose a way to deal with the "legacy" capability URIs we have in NETCONF. If you think trying to solve this issue sucks, fine. But then be careful that the YANG modules for NETCONF and NETCONF extensions do not overload things in wired ways. The with-default says there is a parameter attached to indicate the default default handling and this is not expressed using features. So please fix this. I do not care whether there is a formal capabilities statement to handle the legacy NETCONF capabilities or whether we deal with this in description clauses. But we should stick to the YANG way of doing things as much as we can from now on. And the YANG way to indicate the default default handling would be to define features for all options and to use the YANG mechanism to announce which of them is implemented by a server. /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 Thu Aug 6 08:47: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 9D9373A6C80 for ; Thu, 6 Aug 2009 08:47:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.495 X-Spam-Level: X-Spam-Status: No, score=-2.495 tagged_above=-999 required=5 tests=[AWL=0.104, 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 TUykVAsWlmzc for ; Thu, 6 Aug 2009 08:47:29 -0700 (PDT) Received: from smtp107.sbc.mail.mud.yahoo.com (smtp107.sbc.mail.mud.yahoo.com [68.142.198.206]) by core3.amsl.com (Postfix) with SMTP id BD13D28C102 for ; Thu, 6 Aug 2009 08:47:29 -0700 (PDT) Received: (qmail 19458 invoked from network); 6 Aug 2009 15:47:18 -0000 Received: from unknown (HELO ?192.168.0.10?) (andy@67.125.157.61 with plain) by smtp107.sbc.mail.mud.yahoo.com with SMTP; 6 Aug 2009 15:47:17 -0000 X-YMail-OSG: 6oER7tUVM1nrVxPu_l.qSZ7V7IIzbYjU_Ep985EiVQCe2t8MqJXfw1QyoMSeQCUcRRd7pq0SaAVkEleS8Lc_FDp1rAyPaiJCb.Wc.CrNTd0kQ2pXZ_2qka2QApqm_oSupikPk209lqnwkCdxnPWnYGu1VgH8MTpHl.mEI7.kvQzddaBpD93v43sv03wrdanYKMmKk10OpCIUiQklWCmbi8l82.no.J0uN6mFHsHfxsbjybXxbt3MrcZxaNkFenntM3CxCV19EPowIjg- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4A7AFA9B.8030504@netconfcentral.com> Date: Thu, 06 Aug 2009 08:45:31 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.22 (X11/20090608) MIME-Version: 1.0 To: NETCONF Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [Netconf] too many optional components? 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, 06 Aug 2009 15:47:30 -0000 Hi, I am starting to wonder if so many interacting optional components in the NETCONF protocol is such a good idea. We are still early in the technology curve with NETCONF, and already it is obvious that just the variants from the 10 or so capabilities already defined are leading to lots of interoperability issues. The interactions grow with N^^2, so 20 capabilities will be 4 times worse, not twice as bad as now. Every new NETCONF draft introduces at least 1 (sometimes 2) new capabilities, and we are on track to reach 20 capabilities in less than 3 years. Assuming a 15 - 20 year standards track lifetime, we could have 100,000 valid variants of the NETCONF standard by the time we're done. That's great for an agent developer, who just wants to use NETCONF buffet-style. But it looks like 'worst nightmare ever' to an NMS developer who has to support lots of different agents. Andy From mehmet.ersue@nsn.com Thu Aug 6 08:55: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 38AC23A69D4 for ; Thu, 6 Aug 2009 08:55:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.329 X-Spam-Level: X-Spam-Status: No, score=-3.329 tagged_above=-999 required=5 tests=[AWL=-0.731, 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 iLd0Ki35iBWs for ; Thu, 6 Aug 2009 08:55:26 -0700 (PDT) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [217.115.75.234]) by core3.amsl.com (Postfix) with ESMTP id 61A693A698E for ; Thu, 6 Aug 2009 08:55:25 -0700 (PDT) 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 n76FtRkj002147 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Thu, 6 Aug 2009 17:55:27 +0200 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 n76FtQLm008473 for ; Thu, 6 Aug 2009 17:55:26 +0200 Received: from DEMUEXC005.nsn-intra.net ([10.150.128.17]) by demuexc022.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Thu, 6 Aug 2009 17:55:26 +0200 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_01CA16AE.506E3349" Date: Thu, 6 Aug 2009 17:55:26 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: RE: [Netconf] WGLC: draft-ietf-netconf-with-defaults-02 Thread-Index: AcoWrlBFDtwDKZw6SUW63oKcwF/PPw== From: "Ersue, Mehmet (NSN - DE/Munich)" To: X-OriginalArrivalTime: 06 Aug 2009 15:55:26.0781 (UTC) FILETIME=[50B796D0:01CA16AE] Subject: Re: [Netconf] WGLC: draft-ietf-netconf-with-defaults-02 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, 06 Aug 2009 15:55:27 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CA16AE.506E3349 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, I reviewed the I-D draft-ietf-netconf-with-defaults-03.txt for WGLC. Please find my comments below. Abstract - s/manger/manager/ Ch. 1. Introduction - Last paragraph: I agree their is no explicite statement on default/non-default=20 handling in RFC 4741.=20 OTOH RFC 4741 says that in case a filter element is not=20 defined the "entire configuration" is returned for a=20 operation. As a native reader of the standard I interprete this as=20 the default behaviour of NETCONF protocol, where both,=20 default and non-default data, are returned.=20 But the With-default draft assumes the opposite, i.e. the=20 default behaviour of the NETCONF protocol is to suppress=20 the default data in message. I think we need to align the two documents by choosing=20 one of the options: a) add a clear statement to 4741bis saying that=20 "the agent MAY suppress the default data" or b) address the assumption of a native 4741 reader=20 in With-defaults draft I mentioned above. Ch. 1.1.2. NETCONF Terms I agree that if the default is '3' and the value is '3', it is=20 considered to contain the default, regardless of how it=20 was created. The draft does not specify explicitly set (default) data=20 clearly. How do we handle non-default values which have been=20 set explicitely, where the default is '3' but the value is=20 _not_ '3' ? Are they suppressed too?=20 Ch. 1.2. Current handling of default data - Change: o explicit: Report values if they are explicitly set. =20 For state data this has the same effect as report-all to o explicit: Report values if they are explicitly set and=20 match the default. For state data this has the same=20 effect as report-all - s/report-all/report-all./ Ch. 2.5. Modifications to Existing Operations - Enclose the example code in and=20 as a preparation for the code licence=20 statement. Ch. 4. Data Model XSD - I checked the XSD model for it's validity. The XSD=20 model is valid. - Unfortunately we have still the policy in O&M area to=20 use XSD as the normative language for data models. If we want to publish the With-defaults draft soon I would suggest to follow the example of Partial Lock=20 draft and indicate the XSD as normative.=20 To keep them together I would put the XSD schema=20 and YANG module into the appendix.=20 OTOH if the authors and the WG decide that the=20 With-default draft should be published together=20 with 4747bis and after the publication of YANG=20 we can mark the YAM as normative. In this case=20 there is no need for XSD at all. Change log - 01-02: says "Placeholder for YAM added, XSD will be=20 removed when 4741 provides the NETCONF YAM." We cannot remove the XSD if this draft gets=20 published before YANG becomes normative. Cheers, Mehmet=20 From: netconf-bounces@ietf.org [mailto:netconf-bounces@ietf.org] On Behalf Of ext Ersue, Mehmet (NSN - DE/Munich) Sent: Monday, August 03, 2009 11:42 PM To: netconf@ietf.org Subject: [Netconf] WGLC: draft-ietf-netconf-with-defaults-02 Dear NETCONF WG,=20 we had a good progress on the draft "With-defaults capability=20 for NETCONF". In the NETCONF session at IETF we decided to=20 bring the draft to WGLC to initiate additional discussion.=20 With this mail we start a WGLC for the "With-defaults capability=20 for NETCONF" draft, which is planned to publish as a Proposed=20 Standard RFC. The WGLC will run until August 21, 2009.=20 Everybody on the NETCONF WG maillist PLEASE REVIEW the=20 draft and send your comments to the NETCONF maillist.=20 (http://tools.ietf.org/html/draft-ietf-netconf-with-defaults-02)=20 Thank you and looking forward for your comments.=20 Cheers,=20 Mehmet=20 ------_=_NextPart_001_01CA16AE.506E3349 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable RE: [Netconf] WGLC: draft-ietf-netconf-with-defaults-02

Hi,

I reviewed the I-D = draft-ietf-netconf-with-defaults-03.txt
for WGLC. Please find my comments = below.

Abstract
- s/manger/manager/

Ch. 1.  Introduction
- Last paragraph:
I agree their is no explicite = statement on default/non-default
handling in RFC 4741.
OTOH RFC 4741 says that in case a = filter element is not
defined the "entire = configuration" is returned for a
<get-config> operation.
As a native reader of the standard I = interprete this as
the default behaviour of NETCONF = protocol, where both,
default and non-default data, are = returned.

But the With-default draft assumes = the opposite, i.e. the
default behaviour of the NETCONF = protocol is to suppress
the default data in = <rpc-reply> message.

I think we need to align the two = documents by choosing
one of the options:
a) add a clear statement to 4741bis = saying that
"the agent MAY suppress the = default data" or
b) address the assumption of a = native 4741 reader
in With-defaults draft I mentioned = above.

Ch. 1.1.2. NETCONF Terms

I agree that if the default is '3' = and the value is '3', it is
considered to contain the default, = regardless of how it
was created.

The draft does not specify explicitly = set (default) data
clearly.
How do we handle non-default values = which have been
set explicitely, where the default = is '3' but the value is
_not_ '3' ? Are they suppressed too? =


Ch. 1.2. Current handling of default = data

- Change:
   o  explicit: = Report values if they are explicitly set. 
       = For state data this has the same effect as report-all
to
   o  explicit: = Report values if they are explicitly set and
       = match the default.  For state data this has the same
       = effect as report-all

- s/report-all/report-all./


Ch. 2.5. Modifications to Existing = Operations

- Enclose the example code in = <CODE BEGINS> and
<CODE ENDS> as a preparation = for the code licence
statement.

Ch. 4. Data Model XSD

- I checked the XSD model for it's = validity. The XSD
model is valid.

- Unfortunately we have still the = policy in O&M area to
use XSD as the normative language = for data models.
If we want to publish the = With-defaults draft soon I
would suggest to follow the example = of Partial Lock
draft and indicate the XSD as = normative.
To keep them together I would put = the XSD schema
and YANG module into the appendix. =

OTOH if the authors and the WG decide = that the
With-default draft should be = published together
with 4747bis and after the = publication of YANG
we can mark the YAM as normative. In = this case
there is no need for XSD at = all.

Change log - 01-02:
says "Placeholder for YAM = added, XSD will be
removed when 4741 provides the = NETCONF YAM."

We cannot remove the XSD if this = draft gets
published before YANG becomes = normative.

Cheers,
Mehmet

From: netconf-bounces@ietf.org [mailto:netconf-bounces@ietf.org] On = Behalf Of ext Ersue, Mehmet = (NSN - DE/Munich)
Sent: Monday, August 03, 2009 11:42 PM
To: netconf@ietf.org
Subject: [Netconf] WGLC: = draft-ietf-netconf-with-defaults-02
Dear NETCONF WG,=20
we had a good progress on the draft = "With-defaults capability
for NETCONF". In the NETCONF = session at IETF we decided to
bring the draft to WGLC to initiate = additional discussion.
With this mail we start a WGLC for = the "With-defaults capability
for NETCONF" draft, which is = planned to publish as a Proposed
Standard RFC. The WGLC will run until = August 21, 2009.=20
Everybody on the NETCONF WG maillist = PLEASE REVIEW the
draft and send your comments to the = NETCONF maillist.
(<= U>http://tools.ietf.org/html/draft-ietf-netconf-with-defau= lts-02)=20
Thank you and looking forward for = your comments.=20
Cheers,
Mehmet=20


------_=_NextPart_001_01CA16AE.506E3349-- From andy@netconfcentral.com Thu Aug 6 09:06: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 159753A6A1F for ; Thu, 6 Aug 2009 09:06:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[AWL=-0.498, BAYES_00=-2.599, J_CHICKENPOX_210=0.6, J_CHICKENPOX_81=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 uJrFv-09aIzr for ; Thu, 6 Aug 2009 09:06:37 -0700 (PDT) Received: from smtp105.sbc.mail.mud.yahoo.com (smtp105.sbc.mail.mud.yahoo.com [68.142.198.204]) by core3.amsl.com (Postfix) with SMTP id 19BF73A6B6E for ; Thu, 6 Aug 2009 09:06:37 -0700 (PDT) Received: (qmail 97282 invoked from network); 6 Aug 2009 16:06:38 -0000 Received: from unknown (HELO ?192.168.0.10?) (andy@67.125.157.61 with plain) by smtp105.sbc.mail.mud.yahoo.com with SMTP; 6 Aug 2009 16:06:38 -0000 X-YMail-OSG: 9GYla_AVM1msLMy2tV3YtBxKAcxW6cRUMZt2lInTAZzs0y8JGsIzIIegzd8tiwP4JCTacpFIhjM6PlBOO.94hUGnQ.kbIRSJU8KSNlTsdzsnOOQNxyiDI_0E9Z0LOcyhQuQ81lSI.241A7hF9OcGk23mdBna1SZ01k7qEtvp9C6LO0eLI3KIRy5CaXcfBkGFOxxhbzBRHgji0SHJJAtqaWWNPV2z5B.RfUYnjs9ena.ziAw8tUlgpDYkMPlPF2dwatrWACdIJahopvE- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4A7AFF46.8040708@netconfcentral.com> Date: Thu, 06 Aug 2009 09:05:26 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.22 (X11/20090608) MIME-Version: 1.0 To: Andy Bierman , Balazs Lengyel , netconf mailing list References: <4A7984EA.4000703@ericsson.com> <20090806111305.GA3340@elstar.local> <4A7AF036.30400@netconfcentral.com> <20090806151832.GA1013@elstar.local> In-Reply-To: <20090806151832.GA1013@elstar.local> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [Netconf] [Fwd: New Version Notification for draft-ietf-netconf-with-defaults-03] 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, 06 Aug 2009 16:06:38 -0000 Juergen Schoenwaelder wrote: > On Thu, Aug 06, 2009 at 05:01:10PM +0200, Andy Bierman wrote: >> Juergen Schoenwaelder wrote: >>> On Wed, Aug 05, 2009 at 03:11:06PM +0200, Balazs Lengyel wrote: >>> >>>> Sorry for doing this in the middle of WG Last call, but I posted a >>>> new draft. I realized that it would be important to include the >>>> non-normative YAM in the WG last call. >>> Here is my review of the -03 version of this document. The comments >>> are in document order. >>> >>> s /often needs a single/needs a single/ >>> >>> The text talks about "controls whether default data is part of NETCONF >>> messages"; I would prefer if the text would say that it >>> "extends the NETCONF , , and operations >>> with an additional parameter that allows the NETCONF client to control >>> whether default data is returned in the result. I think we should take >>> the layered architecture of NETCONF serious. This change affects >>> several places of the document since it should nowhere talk about >>> messages. >>> >>> I am not sure how we deal with capabilities within YANG. What about >>> having the ietf-netconf.yang introduce a nc:capability extension >>> statement that can be used to define the capability URI for a YANG >>> feature, just of usage to describe NETCONF protocol extensions? I >>> am thinking of >>> >>> extension nc:capability { >>> description >>> "This extension is used to define capability URIs in NETCONF >>> protocol modules written in YANG. It is not supposed to be >>> used outside of NETCONF protocol specifications."; >>> argument "uri"; >>> } >>> >> >> I am strongly opposed to using extensions to add standard >> mechanisms to the YANG language. The capability-stmt has >> been brought up many times before and rejected every time. >> >> YANG does not care about NETCONF capabilities. >> It is a short-sighted, and architecturally immature >> decision, but it is the NETMOD WG decision. >> >> So all NETCONF capabilities need to be defined as YANG features >> instead. >> >> >>> This way, the features used to define protocol capabilities could >>> indicate the capability URI associated with a protocol "feature". I >>> also note that the with-defaults ID adds special parameters to the >>> capability URI which is something we do not have special support for >>> in YANG - think the YANG approach would be to define feature and to >>> use the feature announcement mechanism. Why do we do something special >>> here? >>> >> If this is part of YANG, it needs to be done with normal >> language constructs. This proposal does not seem to mesh >> at all with the YANG module capability URI encoding. >> Why do we need a separate URI for these capabilities? >> Just advertise the module-uri with features=a,b,c at the end, >> and it serves the same purpose. Why separate the feature 'a' >> out into its own capability URI? > > All I tried to do was to propose a way to deal with the "legacy" > capability URIs we have in NETCONF. If you think trying to solve this > issue sucks, fine. But then be careful that the YANG modules for I object to extensions that every YANG tool must support. What's the point of that? Make it a keyword. So let's add capability-stmt as an optional child of feature-stmt: feature candidate { description "NETCONF :candidate capability; If the agent advertises the :candidate capability for a session, then this feature must also be enabled for that session. Otherwise, this feature must not be enabled."; reference "RFC XXXX, section 8.3."; capability "urn:ietf:params:netconf:capability:candidate:1.0"; } The capability-stmt is used to indicate that a legacy NETCONF capability URI is mapped to this YANG feature. Every YANG compiler MUST support it (opposite of extensions) so a developer can rely on it. > NETCONF and NETCONF extensions do not overload things in wired > ways. The with-default says there is a parameter attached to indicate > the default default handling and this is not expressed using features. > So please fix this. I prefer to make with-defaults wait until YANG is done, and ONLY have a YANG module with read-only 'basic' and 'extended' leafs to indicate the agent's default handling behavior. The use of a capability instead of a YANG data model is a total hack. > > I do not care whether there is a formal capabilities statement to > handle the legacy NETCONF capabilities or whether we deal with this in > description clauses. But we should stick to the YANG way of doing > things as much as we can from now on. And the YANG way to indicate the > default default handling would be to define features for all options > and to use the YANG mechanism to announce which of them is implemented > by a server. > > /js > Andy From j.schoenwaelder@jacobs-university.de Thu Aug 6 12:15: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 34C553A6E68 for ; Thu, 6 Aug 2009 12:15:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.202 X-Spam-Level: X-Spam-Status: No, score=-2.202 tagged_above=-999 required=5 tests=[AWL=0.047, 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 U2EEHygDSf3L for ; Thu, 6 Aug 2009 12:15:04 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 139DC3A6E4F for ; Thu, 6 Aug 2009 12:14:55 -0700 (PDT) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id 7D605C0008; Thu, 6 Aug 2009 21:14:57 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius1.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 1g6u0aopUIdt; Thu, 6 Aug 2009 21:14:56 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id E2C35C0002; Thu, 6 Aug 2009 21:14:55 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id C0DC3B7D40D; Thu, 6 Aug 2009 21:14:54 +0200 (CEST) Date: Thu, 6 Aug 2009 21:14:54 +0200 From: Juergen Schoenwaelder To: "Ersue, Mehmet (NSN - DE/Munich)" Message-ID: <20090806191454.GA1107@elstar.local> Mail-Followup-To: "Ersue, Mehmet (NSN - DE/Munich)" , "netconf@ietf.org" References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.19 (2009-01-05) Cc: "netconf@ietf.org" Subject: Re: [Netconf] WGLC: draft-ietf-netconf-with-defaults-02 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: Thu, 06 Aug 2009 19:15:05 -0000 On Thu, Aug 06, 2009 at 05:55:26PM +0200, Ersue, Mehmet (NSN - DE/Munich) wrote: > Ch. 1. Introduction > - Last paragraph: > I agree their is no explicite statement on default/non-default > handling in RFC 4741. > OTOH RFC 4741 says that in case a filter element is not > defined the "entire configuration" is returned for a > operation. > As a native reader of the standard I interprete this as > the default behaviour of NETCONF protocol, where both, > default and non-default data, are returned. That is _your_ interpretation of what config data is, but there are other possible interpretations where default values are not part of the config. In most Unix config files, you do not set the defaults since they are implicitely there. > But the With-default draft assumes the opposite, i.e. the > default behaviour of the NETCONF protocol is to suppress > the default data in message. I think it says implementation behaviour is not defined in RFC 4741 and this is why the with-defaults document exists. > I think we need to align the two documents by choosing > one of the options: > a) add a clear statement to 4741bis saying that > "the agent MAY suppress the default data" or > b) address the assumption of a native 4741 reader > in With-defaults draft I mentioned above. I assume a) is what we have to in 4741bis. > I agree that if the default is '3' and the value is '3', it is > considered to contain the default, regardless of how it > was created. This is one interpretation, but not all systems have this interpretation. > The draft does not specify explicitly set (default) data > clearly. This is the interpretation where 3 is the default value but there was an explicit management operation to set the value to 3 and thus this value now becomes part of the config (because it was explicitely set, not because of the value itself). > How do we handle non-default values which have been > set explicitely, where the default is '3' but the value is > _not_ '3' ? Are they suppressed too? In this model, everything explicitly set is config data - the value does not matter. It matters that the value was explicitely set. We probably need some more text plus an example to describe these three models more clearly. /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 Thu Aug 6 13:31:44 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 791533A6E23 for ; Thu, 6 Aug 2009 13:31:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.281 X-Spam-Level: X-Spam-Status: No, score=-5.281 tagged_above=-999 required=5 tests=[AWL=1.317, 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 PpTT2Do6wM9W for ; Thu, 6 Aug 2009 13:31:43 -0700 (PDT) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [217.115.75.233]) by core3.amsl.com (Postfix) with ESMTP id 48DAB3A69C6 for ; Thu, 6 Aug 2009 13:31:42 -0700 (PDT) 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 n76KViPu020530 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 6 Aug 2009 22:31:44 +0200 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 n76KVi2m019891; Thu, 6 Aug 2009 22:31:44 +0200 Received: from DEMUEXC005.nsn-intra.net ([10.150.128.17]) by demuexc022.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Thu, 6 Aug 2009 22:31:44 +0200 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_01CA16D4.E91FAAF3" Date: Thu, 6 Aug 2009 22:31:42 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Text clarification for 4741bis WAS:RE: [Netconf] WGLC: draft-ietf-netconf-with-defaults-02 Thread-Index: AcoW1OgoJycCgJweTwWbuvskedwiEw== From: "Ersue, Mehmet (NSN - DE/Munich)" To: "Juergen Schoenwaelder" , X-OriginalArrivalTime: 06 Aug 2009 20:31:44.0097 (UTC) FILETIME=[E9914510:01CA16D4] Subject: [Netconf] Text clarification for 4741bis WAS:RE: WGLC: draft-ietf-netconf-with-defaults-02 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, 06 Aug 2009 20:31:44 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CA16D4.E91FAAF3 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable > From: ext Juergen Schoenwaelder Thursday, August 06, 2009 9:15 PM >=20 > On Thu, Aug 06, 2009 at 05:55:26PM +0200, Ersue, Mehmet (NSN=20 > - DE/Munich) wrote: > =20 > > Ch. 1. Introduction > > - Last paragraph: > > I agree their is no explicite statement on default/non-default > > handling in RFC 4741. > > OTOH RFC 4741 says that in case a filter element is not > > defined the "entire configuration" is returned for a > > operation. > > As a native reader of the standard I interprete this as > > the default behaviour of NETCONF protocol, where both, > > default and non-default data, are returned. >=20 > That is _your_ interpretation of what config data is, but there are > other possible interpretations where default values are not part of > the config. In most Unix config files, you do not set the defaults > since they are implicitely there. >=20 > > But the With-default draft assumes the opposite, i.e. the > > default behaviour of the NETCONF protocol is to suppress > > the default data in message. >=20 > I think it says implementation behaviour is not defined in RFC 4741 > and this is why the with-defaults document exists. >=20 > > I think we need to align the two documents by choosing > > one of the options: > > a) add a clear statement to 4741bis saying that > > "the agent MAY suppress the default data" or > > b) address the assumption of a native 4741 reader > > in With-defaults draft I mentioned above. >=20 > I assume a) is what we have to in 4741bis. Agree, we should add a clear statement to 4741bis for this. Cheers, Mehmet ------_=_NextPart_001_01CA16D4.E91FAAF3 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Text clarification for 4741bis WAS:RE: [Netconf] WGLC: = draft-ietf-netconf-with-defaults-02

> From: ext Juergen = Schoenwaelder Thursday, August 06, 2009 9:15 PM
>
> On Thu, Aug 06, 2009 at = 05:55:26PM +0200, Ersue, Mehmet (NSN
> - DE/Munich) wrote:
> 
> > Ch. 1.  = Introduction
> > - Last = paragraph:
> > I agree their is no = explicite statement on default/non-default
> > handling in RFC = 4741.
> > OTOH RFC 4741 says = that in case a filter element is not
> > defined the = "entire configuration" is returned for a
> > <get-config> = operation.
> > As a native reader of = the standard I interprete this as
> > the default behaviour = of NETCONF protocol, where both,
> > default and = non-default data, are returned.
>
> That is _your_ = interpretation of what config data is, but there are
> other possible = interpretations where default values are not part of
> the config. In most Unix = config files, you do not set the defaults
> since they are implicitely = there.
>
> > But the With-default = draft assumes the opposite, i.e. the
> > default behaviour of = the NETCONF protocol is to suppress
> > the default data in = <rpc-reply> message.
>
> I think it says = implementation behaviour is not defined in RFC 4741
> and this is why the = with-defaults document exists.
>
> > I think we need to = align the two documents by choosing
> > one of the = options:
> > a) add a clear = statement to 4741bis saying that
> > "the agent MAY = suppress the default data" or
> > b) address the = assumption of a native 4741 reader
> > in With-defaults draft = I mentioned above.
>
> I assume a) is what we have = to in 4741bis.

Agree, we should add a clear = statement to 4741bis for this.

Cheers,
Mehmet

------_=_NextPart_001_01CA16D4.E91FAAF3-- From mehmet.ersue@nsn.com Thu Aug 6 13:47: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 A77F428C16F for ; Thu, 6 Aug 2009 13:47:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.263 X-Spam-Level: X-Spam-Status: No, score=-2.263 tagged_above=-999 required=5 tests=[AWL=-1.865, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_BACKHAIR_34=1, J_CHICKENPOX_22=0.6, 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 74+sG0h4+lGE for ; Thu, 6 Aug 2009 13:47:25 -0700 (PDT) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [217.115.75.234]) by core3.amsl.com (Postfix) with ESMTP id 6E03028C141 for ; Thu, 6 Aug 2009 13:47:24 -0700 (PDT) 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 n76KlLdL017385 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 6 Aug 2009 22:47:21 +0200 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 n76KlLAc005844; Thu, 6 Aug 2009 22:47:21 +0200 Received: from DEMUEXC005.nsn-intra.net ([10.150.128.17]) by demuexc023.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Thu, 6 Aug 2009 22:47:21 +0200 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_01CA16D7.17BAC51E" Date: Thu, 6 Aug 2009 22:47:19 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Draft minutes for IETF #75 NETCONF session Thread-Index: AcoW1xdHeEHPoSeTQ5OOdlcZPTH7Sg== From: "Ersue, Mehmet (NSN - DE/Munich)" To: X-OriginalArrivalTime: 06 Aug 2009 20:47:21.0231 (UTC) FILETIME=[182491F0:01CA16D7] Subject: [Netconf] Draft minutes for IETF #75 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: Thu, 06 Aug 2009 20:47:26 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CA16D7.17BAC51E Content-Type: multipart/alternative; boundary="----_=_NextPart_002_01CA16D7.17BAC51E" ------_=_NextPart_002_01CA16D7.17BAC51E Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dear NETCONF WG, attached are the draft minutes for the NETCONF session=20 at IETF #75. Many thanks to Lada and Juergen for taking the minutes=20 and David P for scribing and channeling the jabber room! Please review the minutes and let us know your change=20 requests or comments by August 12, 2009 EOB. Thanks. <>=20 Mehmet & Bert ------_=_NextPart_002_01CA16D7.17BAC51E Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Draft minutes for IETF #75 NETCONF session

Dear NETCONF WG,

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

Many thanks to Lada and Juergen for = taking the minutes
and David P for scribing and = channeling the jabber room!

Please review the minutes and let us = know your change
requests or comments by August 12, = 2009 EOB. Thanks.

<<Draft_IETF = 75_NETCONF Minutes.txt>>
Mehmet & Bert

------_=_NextPart_002_01CA16D7.17BAC51E-- ------_=_NextPart_001_01CA16D7.17BAC51E Content-Type: text/plain; name="Draft_IETF 75_NETCONF Minutes.txt" Content-Transfer-Encoding: base64 Content-Description: Draft_IETF 75_NETCONF Minutes.txt Content-Disposition: attachment; filename="Draft_IETF 75_NETCONF Minutes.txt" LS0tLSBEcmFmdCAwNi4wOC4wOQ0KDQpNaW51dGVzIG9mIHRoZSBOZXR3b3JrIENvbmZpZ3VyYXRp b24gKE5FVENPTkYpIFdHIFNlc3Npb24gYXQgdGhlIElFVEYgIzc1LA0KVFVFU0RBWSwgSnVseSAy OCAyMDA5LCAxMzAwLTE1MDA6DQoNCldHIENoYWlyczoNCkJlcnQgV2lqbmVuIDxiZXJ0aWV0ZkBi d2lqbmVuLm5ldD4NCk1laG1ldCBFcnN1ZSA8bWVobWV0LmVyc3VlQG5zbi5jb20+DQpBRDogRGFu IFJvbWFzY2FudSA8ZHJvbWFzY2FAYXZheWEuY29tPg0KDQpNYW55IFRoYW5rcyB0byB0aGUgbWlu dXRlIHRha2VyczogSnVlcmdlbiBTY2hvZW53YWVsZGVyIGFuZCBMYWRpc2xhdiBMaG90a2ENCmFu ZCB0aGUgamFiYmVyIHNjcmliZTogRGF2aWQgUGFydGFpbiAoYWxzbyBmb3IgY2hhbm5lbGluZyB0 aGUgamFiYmVyZWVzIG9uIG1pY3JvcGhvbmUpLg0KDQpUaGVyZSB3ZXJlIGFwcHJveC4gMzcgcGVy c29ucyBpbiB0aGUgTkVUQ09ORiBzZXNzaW9uLg0KDQoNCiogQWRtaW5pc3RyaXZpYSBhbmQgYWdl bmRhIGJhc2hpbmcNCg0KICAtIHNlZSBzbGlkZXM6ICBodHRwOi8vd3d3LmlldGYub3JnL3Byb2Nl ZWRpbmdzLzc1L2FnZW5kYS9uZXRjb25mLnR4dA0KICAtIG5vIGNoYW5nZXMNCg0KKiBXRyBTdGF0 dXMgKE1laG1ldCkNCiAgLSBXRyBzdGF0dXMgcmV2aWV3ZWQuDQogIC0gc2VlIHNsaWRlczogIGh0 dHA6Ly93d3cuaWV0Zi5vcmcvcHJvY2VlZGluZ3MvNzUvc2xpZGVzL25ldGNvbmYtMC5wcHQNCiAg LSBwYXJ0aWFsLWxvY2sgSS1EIGlzIG5vdyBpbiB0aGUgSUVTRyBldmFsdWF0aW9uIHF1ZXVlDQog IC0gbW9uaXRvcmluZyBJLUQ6IFdHTEMgZW5kZWQgMjQgSnVseSwgV0cgc2hvdWxkIGRlY2lkZSB3 aGV0aGVyIC0wNyBpcyByZWFkeSBmb3IgQUQgcmV2aWV3DQogIC0gcm9idXN0IGNvbmYuIG1hbmFn ZW1lbnQgY3JlYXRlZCBzb21lIGludGVyZXN0LCBXRyBuZWVkcyB0byBkZWNpZGUgYWJvdXQgcmVj aGFydGVyaW5nDQogIC0gbm8gZGlzY3Vzc2lvbg0KDQoqIE5FVENPTkYgTW9uaXRvcmluZyAoTWFy dGluKQ0KDQogIC0gRmV3IHVwZGF0ZXMgc2luY2UgbGFzdCB2ZXJzaW9uLCBJLUQgcXVpdGUgc3Rh YmxlLCBzaG91bGQgYmUgcmVhZHkgZm9yIFdHTEMuDQogIC0gc2VlIHNsaWRlczogaHR0cDovL3d3 dy5pZXRmLm9yZy9wcm9jZWVkaW5ncy83NS9zbGlkZXMvbmV0Y29uZi0xLnBwdA0KDQogIC0gSlMg YXNrcyB3aGV0aGVyIHRoZSBZQU5HIG1vZHVsZSdzIGRlcGVuZGVuY2UgaXMgYW4gaXNzdWUNCiAg LSBNRSBhbnN3ZXJzIHRoYXQgdGhlIGFwcGVuZGl4IGlzIG5vbi1ub3JtYXRpdmUgc28gaXQgaXMg bm90IGFuIGlzc3VlDQoNCiAgLSBKUyBhc2tzIGZvciBzb21lIGFkZGl0aW9uYWwgdGltZSB0byBj aGVjayB0aGUgdGhhdCBJUCBhZGRyZXNzIHR5cGVzIGFyZSBjb25zaXN0ZW50IHdpdGggeWFuZy10 eXBlcw0KICAtIE1FIHNheXMgdGhpcyBjaGVjayBpcyB3ZWxjb21lDQoNCiAgLSBCVyBhc2tzIHdo ZXRoZXIgdGhlIFhTRCB3YXMgYXV0b2dlbmVyYXRlZCBmcm9tIFlBTkc/DQogIC0gTUIgc2F5cyBu byBiZWNhdXNlIGl0IGlzIGEgc3RhbmRhbG9uZSB0b29sIGFuZCBYU0QgaGFzIGl0cyBvd24gY29t cGxleCB0eXBlIGZvciBJUCBhZGRyZXNzZXMuDQoNCiAgLSBEUiBJcyBZQU5HIGludGVuZGVkIHRv IGJlIGV2ZW50dWFsbHkgbm9ybWF0aXZlPw0KICAtIEdlbmVyYWwgY29uc2Vuc3VzIGNvbmZpcm1l ZCB0aGF0IGludGVudGlvbi4NCiAgLSBKUyBUaGlzIGRlcGVuZHMgb24gaG93IHNvb24gWUFORyBi ZWNvbWVzIGEgc3RhbmRhcmQuDQogIC0gQlcgTm93IFlBTkcgaXMgbWF0dXJlIHNvIHRoYXQgdGhl cmUgaXMgbm8gcmVhbCBkYW5nZXIgb2YgZGVsYXlpbmcgdGhlIG1vbml0b3JpbmcgZHJhZnQuDQog IC0gRFIgSSB3b3VsZG4ndCBiZSB0aGF0IG9wdGltaXN0aWMuDQogIC0gQUIob24gSmFiYmVyKTog SG93IGNhbiB0aGUgbW9uaXRvcmluZyBkcmFmdCBwcmVjZWRlIHRoZSBwYXJ0aWFsLWxvY2sgZHJh ZnQ/DQogIC0gQlcgcGFydGlhbC1sb2NrIGlzIG5vdyBhdCBJRVNHLg0KICAtIEJXIERvIHdlIHdh bnQgdG8gbWFrZSBZQU5HIG5vcm1hdGl2ZT8NCiAgLSBEUiBXaHkgaXMgaXQgc28gaW1wb3J0YW50 Pw0KICAtIFBTIChpKSB0aGUgZGF0YSBtb2RlbCBpcyBuaWNlciwgKGlpKSBpdCdzIGEgdXNlZnVs IGV4ZXJjaXNlIGZvciBZQU5HLCAoaWlpKSBZQU5HIGhhcyBiZXR0ZXIgZGF0YSB0eXBlcy4NCiAg LSBNUyBEbyB3ZSB3YW50IHRvIHdhaXQgd2l0aCBvdGhlciBkYXRhIG1vZGVscyB1bnRpbCBZQU5H IGlzIGZpbmlzaGVkPw0KDQogIC0gUFMgYXNrcyB3aGV0aGVyIHdlIGNhbiB3YWl0IGFuZCBtYWtl IHRoZSBZQU5HIG5vcm1hdGl2ZT8NCiAgLSBEUiBzYXlzIHlvdSBjYW4gcHJvZ3Jlc3MgdGhlIGRv Y3VtZW50IGFuZCBpdCB3aWxsIHN0YXkgaW4gdGhlIFJGQyBlZGl0b3IgcXVldWUgdW50aWwgdGhl IFlBTkcgZG9jdW1lbnRzIGNvbWUgb3V0DQogIC0gQlcgZXhwbGFpbnMgdGhhdCB0aGVyZSBpcyBv ZiBjb3Vyc2UgYSByaXNrIGluIGNhc2UgWUFORyBjaGFuZ2VzIGFmZmVjdGluZyB0aGUgZG9jdW1l bnQgY2FuIGNhdXNlIHRyb3VibGUNCg0KICAtIE1FIGFzIGNvbnRyaWJ1dG9yIHNheXMgd2Ugc2hv dWxkIG5vdCBkZWxheSBkcmFmdHMgYWxyZWFkeSBpbiBxdWV1ZQ0KICAtIERQIGFyZSAxLTIgbW9u dGhzIGRlbGF5IHdvcnRoIHRvIHB1Ymxpc2ggYSBkYXRhIG1vZGVsIGluIGEgZm9ybWF0IHdlIGRv IG5vdCBwbGFuIHRvIGNvbnRpbnVlPw0KICAtIEJXIGFncmVlcyB0byB1c2UgWUFORyBhcyBhIHRl Y2huaWNhbCBjb250cmlidXRvciwgYnV0IGFzIGNoYWlyIGhlIGlzIHJlbHVjdGFudCB0byB0ZWxs IHRoZSBhdXRob3JzIHRoaW5ncyBnZXQgZnVydGhlciBkZWxheWVkDQoNCiAgLSBCVyBzdWdnZXN0 cyB0byBtb3ZlIGFoZWFkIHdpdGggWFNEIGFuZCB0aGVuIHVwZGF0ZSB0aGUgUkZDIHF1aWNrbHkg d2l0aCBhIFlBTkcgdmVyc2lvbiBvZiB0aGUgZG9jdW1lbnQNCg0KICAtIEJXIGFza3Mgd2hldGhl ciB0aGVyZSBhcmUgYW55IHN0cm9uZyBvYmplY3RzIGFnYWluc3QgbW92aW5nIGZvcndhcmQgd2l0 aCB0aGUgbm9ybWF0aXZlIFhTRC4gDQogIC0gVGhlcmUgd2VyZSBub24gcmFpc2VkIHNvIHdlIG1v dmUgZm9yd2FyZCB3aXRoIHRoZSBub3JtYXRpdmUgWFNEIGFmdGVyIGNoZWNraW5nIHRoZSBJUCBh ZGRyZXNzIGRhdGEgdHlwZXMuDQoNCiogUkZDIDQ3NDEgUmV2aXNpb24gKE1hcnRpbikNCg0KICAt IHNlZSBzbGlkZXM6IGh0dHA6Ly93d3cuaWV0Zi5vcmcvcHJvY2VlZGluZ3MvNzUvc2xpZGVzL25l dGNvbmYtMi5wZGYNCg0KKiogMDAzOiBlcnJvci1wYXRoDQogIC0gQUIgU29tZXRpbWVzIHdlIGhh dmUgdG8gdXNlIGJvdGggcm9vdHMgaW4gb25lIFBEVS4NCiAgLSBNQiB3aWxsIHByb3Bvc2UgYSBz b2x1dGlvbiBvbiB0aGUgV0cgbGlzdA0KDQoqKiAwMDQ6IGVycm9yLXNldmVyaXR5DQogIC0gQkw6 IFdhcm5pbmdzIGFyZSB1c2VmdWwsIGRvIG5vdCByZW1vdmUsIHJhdGhlciBmaXggdGhlbS4NCiAg LSBKUyBEbyB3ZSBoYXZlIGFueSBldmlkZW5jZSB0aGF0IHdhcm5pbmdzIGFyZSB1c2VmdWwuDQog IC0gTUIgTm8sIGJlY2F1c2UgdGhleSBjYW5ub3QgYmUgY3VycmVudGx5IHVzZWQuDQogIC0gUFMg c2F5cyBKdW5vcyBkb2VzIHN1cHBvcnQgd2FybmluZ3MsIGJ1dCBpbiBhIHByb3ByaWV0YXJ5IHdh eQ0KICAtIFdIIFdhcm5pbmdzIGFyZSB1c2VmdWwsIGlmIHlvdSByZW1vdmUgdGhlbSBub3csIGJl IHN1cmUgeW91IHdpbGwgcHV0IHRoZW0gYmFjayBsYXRlci4NCiAgLSBEUCBhZ3JlZXMuDQogIC0g QlcgYXNrcyB3aG8gcHJlZmVycyB0byBrZWVwIGFuZCBmaXggd2FybmluZ3MuDQogIC0gUm91Z2gg Y29uc2Vuc3VzIGlzIHRvIGtlZXAgd2FybmluZ3MgYnV0IGFsc28gZml4IHRoZW0uDQogIC0gQUIg V2lsbCB0aGUgbmV3IGVycm9yIHRhZyBicmVhayB0aGUgZXhpc3RpbmcgbWFuYWdlcnM/DQogIC0g QlcgTGV0J3MgZGlzY3VzcyBpdCBpbiB0aGUgTUwuDQoNCioqIDAwNjogbXVsdGlwbGUgbmFtZXNw YWNlcw0KICAtIE1CIHByZWZlcnMgdG8gcmVtb3ZlIHRoaXMgZmVhdHVyZQ0KICAtIFBTIHNheXMg dGhpcyB3YXMgYWRkZWQgdG8gc3VwcG9ydCBjb25maWdzIHRoYXQgYXJlIGp1c3QgYSB0ZXh0IGJs b2NrDQogIC0gUFMgVGhlIG91dGNvbWUgKHNlbGVjdGluZyB0aGUgb3V0cHV0IGZvcm1hdCkgaXMg dXNlZnVsLCBzbyB3ZSBzaG91bGQgbWF5YmUgaW50cm9kdWNlIGEgbmV3IGdldC1jb25maWcgcGFy YW1ldGVyIGZvciB0aGUgb3V0cHV0IGZvcm1hdC4NCiAgLSBBQiBJc24ndCB0aGlzIGRhdGEgbW9k ZWwgc3BlY2lmaWM/DQogIC0gTUIgQ3VycmVudCB0ZXh0IGlzbid0Lg0KICAtIEJXIFdlIG5lZWQg dG8gY2xhcmlmeSB0aGUgdGV4dC4NCiAgLSBKUyBzYXlzIHRoYXQgWUFORyBoYXMgZmVhdHVyZXMg YW5kIE5FVENPTkYgaGFzIGNhcGFiaWxpdGllcyBhbmQgd2Ugc2hvdWxkIHdvcmsgd2l0aCB0aGVz ZSBtZWNoYW5pc21zDQogIC0gUFMgWUFORyBtb2RlbCBjYW4gZ2VuZXJhdGUgYm90aCBYTUwgYW5k IHRleHQgKENMSSBvdXRwdXQpLg0KICAtIEFCIHNheXMgYWxsIGNvbnRlbnQgaXMgWE1MIGFuZCB0 ZXh0IHNob3VsZCBiZSB3cmFwcGVkIGluIFhNTA0KICAtIEpTIHN1cHBvcnRzIHJlbW92aW5nIHRo ZSB0ZXh0IG91dHB1dCBmb3JtYXQgb3B0aW9uLg0KICAtIEFCIFRleHQgZm9ybWF0IGlzIG5vdCBk ZWZpbmVkIGFuZCB3ZSBoYXZlIG5vIGZvcm1hbCB3YXkgZm9yIFhNTDwtPnRleHQgY29udmVyc2lv bnMuDQogIC0gQkwgV2UgYWxyZWFkeSBleHByZXNzIGZlYXR1cmVzIGluIHRoZSBjYXBhYmlsaXR5 IFVSSSwgd2UgY2FuIGRvIGl0IGZvciB0aGUgZm9ybWF0IGFzIHdlbGwuDQogIC0gQlcgYXNrcyB3 aGV0aGVyIHRoZSBwZW9wbGUgaW4gdGhlIHJvb20gYXJlIGluIGZhdm91ciBvZiByZW1vdmluZyB0 aGUgdGV4dCBhbmQgdGhhdCB3YXMgdGhlIGNhc2UuIEJlcnQgc2VuZHMgdGhlIGRpc2N1c3Npb24g YmFjayB0byB0aGUgbWFpbGluZyBsaXN0Lg0KDQoqKiAwMTQ6IGNhcGFiaWxpdHkgY2hhbmdlcw0K DQogIC0gQUIgc2F5cyB0aGF0IHRoZSBiYXNlIGNhcGFiaWxpdHkgdmVyc2lvbiBtdXN0IGJlIGlu Y3JlYXNlIHdoZW4gYWRkaW5nIG5ldyBlcnJvci1hcHAtdGFncywgb3RoZXJ3aXNlIHRoZSBleGlz dGluZyBtYW5hZ2VycyB3aWxsIGJyZWFrLg0KICAtIEJMIFdlIGhhdmUgYWxyZWFkeSBhZGRlZCBu ZXcgZXJyb3ItYXBwLXRhZ3MuDQogIC0gUFMgd2FudHMgdG8gaGF2ZSB0ZXh0IHRoYXQgY2xpZW50 cyBzaG91bGQgbm90IGJyZWFrIGlmIGVycm9yLXRhZ3MgYXJlIGFkZGVkIGluIHRoZSBmdXR1cmUN CiAgLSBBQiBhc2tzIHdoZXRoZXIgYSBjYXBhYmlsaXR5IGNoYW5nZWQgbm90aWZpY2F0aW9uIGNv dWxkIHdvcms/DQogIC0gQlcgcmVzcG9uZHMgdGhhdCBhIGNsaWVudCBtaWdodCBub3QgbGlzdGVu IGZvciBzdWNoIGEgbm90aWZpY2F0aW9uDQogIC0gTUIgVGhlIG1hbmFnZXIgbWF5IG5vdCBiZSBz dWJzY3JpYmVkIHRvIHRoZSByaWdodCBjaGFubmVsLg0KICAtIExMIENvdWxkIG9uZSBjaGFubmVs IGJlIG1hZGUgbWFuZGF0b3J5IGZvciBhbGwgbWFuYWdlcnM/DQogIC0gTUIgc2F5cyBhIG5vdGlm aWNhdGlvbiB3b3VsZCBiZSBpbiBhZGRpdGlvbiB0byB0aGUgZXJyb3IgY29kZQ0KICAtIEFCIGlz IGFnYWluc3QgdGhlIGVycm9yLWNvZGUuDQogIC0gTWFyayBFIChPbiBKYWJiZXIpOiBSZXN1bHRp bmcgY2FwYWJpbGl0aWVzIGFyZSB0aGUgaW50ZXJzZWN0aW9uIG9mIGNhcGFiaWxpdGllcyBhZHZl cnRpc2VkIGJ5IHRoZSBjbGllbnQgYW5kIHNlcnZlciwgc28gdGhleSBtdXN0IGJlIHJlbmVnb3Rp YXRlZCBpZiBlaXRoZXIgcGFydCBjaGFuZ2VzIHRoZW0uDQogIC0gQkwgTm90IHRydWUsIGNsaWVu dHMgYXJlIG5vdCBzdXBwb3NlZCB0byBzZW5kIGV2ZXJ5dGhpbmcgdGhleSBzdXBwb3J0Lg0KICAt IEJXIGFza3Mgd2hldGhlciB0aGUgcm9vbSBwcmVmZXJzIHRvIGFkZCBhIGNhcGFiaWxpdHktY2hh bmdlZCBhbmQgdGhlcmUgd2FzIHJvdWdoIGNvbnNlbnN1cyBpbiB0aGUgcm9vbSB0byBhZGQgY2Fw YWJpbGl0eS1jaGFuZ2VkDQoNCioqIDAxNTogVVRGLTggYW5kIFVURi0xNg0KDQogIC0gRFIgc2F5 cyBVVEYtOCBvbmx5IGlzIGZpbmUNCiAgLSBKUyBwcm9wb3NlcyB0byBtYWtlIFVURi04IG1hbmRh dG9yeSBhbmQgdG8gYmUgc2lsZW50IGFib3V0IFVURi0xNg0KICAtIEJXIHBvbGxzIHdoZXRoZXIg YWRkaW5nIHRleHQgcmVxdWlyaW5nIFVURi04IGhhcyBjb25zZW5zdXMgaW4gdGhlDQogICAgcm9v bSBhbmQgdGhpcyBzZWVtcyB0byBiZSB0aGUgY2FzZQ0KDQoqKiAwMTM6IGNvbmZpcm1lZC1jb21t aXQNCg0KICAtIFdIIGV4cGxhaW5zIHRoYXQgdGhlcmUgaXMgYWxzbyBhIGxvY2sgZHJvcHBlZCB3 aGVuIGEgc2Vzc2lvbiBkaXNhcHBlYXJzDQogIC0gSlMgV2hhdCdzIHRoZSByZWxhdGlvbiBiZXR3 ZWVuIGxvY2tzIGFuZCBjb25maXJtZWQtY29tbWl0Pw0KICAtIFdIIGZ1cnRoZXIgY2xhcmlmaWVz IHRoYXQgYSBtYW5hZ2VyIHdhaXRpbmcgZm9yIGEgbG9jayB3aWxsIGdyYWIgdGhlIGxvY2sgYW5k IGJlIHN1cnByaXNlZCBpZiB0aGVyZSBpcyBzdWRkZW5seSBhIHJvbGxiYWNrDQogIC0gQkMgYXNr cyB3aGF0IHRoZSBwcm9ibGVtIGlzIHRvIGJlIHNvbHZlZD8NCiAgLSBXSCBZb3UgY2FuIHRpZSB0 aGUgbG9jayB0byB0aGUgY29uZmlybWVkLWNvbW1pdCBvcGVyYXRpb24gYW5kIHJlbGVhc2UgaXQg b25seSBhZnRlciBpdCBpcyBmaW5pc2hlZC4NCiAgLSBKUyBzYXlzIHRvIHNvbHZlIHRoZSBpc3N1 ZSBXSCByYWlzZWQgd291bGQgYmUgdG8gbm90IGhhbmQgb3V0IGEgbG9jayB3aGlsZSBhIGNvbmZp cm1lZCBjb21taXQgaXMgcGVuZGluZw0KICAtIEJXIHNheXMgdGhpcyBuZWVkcyBtb3JlIHRob3Vn aCBhbmQgZGlzY3Vzc2lvbiBvbiB0aGUgbWFpbGluZyBsaXN0DQoNCioqIDAxMDogbmFtZXNwYWNl IHdpbGRjYXJkaW5nDQoNCiAgLSBNQiBpcyBpbiBmYXZvdXIgb2YgdHJlYXRpbmcgbm8gbmFtZXNw YWNlIGFzIGEgd2lsZGNhcmQNCiAgLSBCTCBzYXlzIHRoaXMgd2lsZGNhcmRpbmcgaXMgb2Z0ZW4g dXNlZCBhbmQgaGUgbGlrZXMgaXQNCiAgLSBNQiBkaXNhZ3JlZXMuDQogIC0gQUIgc2F5cyB0aGlz IGRvZXMgYnJlYWsgWE1MDQogIC0gV0ggc2VlcyB0aGUgdmFsaWQgb2YgdGhlIGZlYXR1cmUgYnV0 IGlzIGNvbmNlcm5lZCBhYm91dCB0aGUgd2F5IGl0IGlzIGRvbmUuIFRoaXMgYXBwcm9hY2ggYnJl YWtzIHRoZSBjb25jZXB0IG9mIFhNTCBuYW1lc3BhY2VzLg0KICAtIFBTIHNheXMgdGhlIGNsaWVu dCBzaG91bGQgYmUgZXhwbGljaXQgdGhhdCBpdCB3YW50cyBhIHdpbGRjYXJkDQogIC0gTUIgYW5k IFBTIGRpc2N1c3MgdGhpbmdzLi4uDQogIC0gTEwgc2F5cyB0aGUgbnVsbCBuYW1lc3BhY2UgY291 bGQgd29yayBmb3IgdGhpcy4gSXQncyBub3RoaW5nIGlsbGVnYWwgZnJvbSB0aGUgcG9pbnQgb2Yg dmlldyBvZiBYTUwgbmFtZXNwYWNlcywgaWYgdGhlIGNsaWVudCBtYWtlcyBzdXJlIHRoYXQgdGhl IG5hbWVzcGFjZSBpcyBwcm9wZXJseSByZW1vdmVkIChieQ0KJ3htbG5zPSIiJykuIFRoZSBvbmx5 IHByb2JsZW0gd291bGQgYmUgaWYgdGhlcmUgYXJlIG90aGVyIGVsZW1lbnRzIHdpdGggbnVsbCBu YW1lc3BhY2UgVVJJLCBidXQgdGhpcyBjYW5ub3QgaGFwcGVuIGluIE5FVENPTkYuDQogIC0gTUIg YWdyZWVzLg0KICAtIEJXIHNheXMgdGhhdCB0aGlzIGlzc3VlIHJlcXVpcmVzIGZ1cnRoZXIgZGlz Y3Vzc2lvbiBvbiB0aGUgbGlzdC4NCg0KKiogMDA5OiBwYXJ0aWFsLW9wZXJhdGlvbiBlcnJvcg0K DQogIC0gQUIgYWdyZWVzIHRvIGRlcHJlY2F0ZSB0aGlzIGVycm9yDQogIC0gQlcgc2F5cyB0aGlz IHdpbGwgZ28gdG8gdGhlIG1haWxpbmcgbGlzdA0KDQoqKiAwMTI6IGZvcm1hdCBvZiBjb3B5LWNv bmZpZw0KDQogIC0gUFMgc2F5cyB0aGF0IEp1bmlwZXIgaXMgbm90IHVzaW5nIG5jOmNvbmZpZyBi dXQgaW5zdGVhZCBhIHZlbmRvcg0KICAgIHNwZWNpZmljIHRvcC1sZXZlbCBub2RlDQogIC0gSlMg SSBhbSBzdGlsbCBjb25mdXNlZCBob3cgdGhpcyB3b3Jrcy4gW1F1ZXN0aW9uIHRvIFBTXSBJcyB0 aGUgb25seSBwcm9ibGVtIHRoZSB0b3AtbGV2ZWwgZWxlbWVudD8NCiAgLSBCTCBhc2tzIHdoZXRo ZXIgd2Ugc2hvdWxkIHN0YXRlIHRoYXQgdGhlIGNvbnRlbnRzIHRoZSBzYW1lIGFzIGdldC1jb25m aWcgd2l0aG91dCBhIGZpbHRlcj8NCiAgLSBCVyBzYXlzIHRoaXMgaXNzdWUgbmVlZHMgbW9yZSBt YWlsaW5nIGxpc3QgZGlzY3Vzc2lvbi4NCg0KKiBXaXRoLWRlZmF1bHRzIChCYWxhc3opDQoNCiAg LSBzZWUgc2xpZGVzOiBodHRwOi8vd3d3LmlldGYub3JnL3Byb2NlZWRpbmdzLzc1L3NsaWRlcy9u ZXRjb25mLTMucHB0DQoNCiAgLSBQUyBzYXlzIHRoYXQgdGhlIHRleHQgdXNlcyBTTk1QIHRlcm1p bm9sb2d5ICJhZ2VudC1tYW5hZ2VyIiwgaXQgc2hvdWxkIHVzZSAiY2xpZW50LXNlcnZlciIgYW5k IHdhbnRzIHRvIGNoYW5nZSB0ZXJtaW5vbG9neSB0byA0NzQxIHRlcm1pbm9sb2d5Lg0KICAtIFBT IGhhcyBzb21lIGRldGFpbGVkIHF1ZXN0aW9ucyBjb25jZXJuaW5nIHRoZSB0ZXh0IGluIHRoZSBJ RA0KICAtIEJMIFRoaXMgdGVybWlub2xvZ3kgaXMgdXNlZCBpbiBvdGhlciBkcmFmdHMsIHRvby4N CiAgLSBQaGlsOiBbZXhwcmVzc2VzIGFub3RoZXIgY29tbWVudCB3cnQgU2VjdGlvbiAyLjEuMV0N CiAgLSBCVyBhc2tzIFBTIHRvIHNlbmQgdGhlIGRldGFpbHMgdG8gdGhlIGxpc3QNCiAgLSBCVyBD YW4gd2UgZGlzY3VzcyB0aGVzZSBlZGl0b3JpYWwgY29tbWVudHMgZHVyaW5nIFdHTEM/DQogIC0g RFAgWWVzLCB0aGVzZSBpdGVtcyBhcmUgc3VpdGFibGUgZm9yIFdHTEMuDQoNCiAgLSBBQiB3cm90 ZSB0byB3ZSBuZWVkIHRvIGRlc2NyaWJlIHdoYXQgaGFwcGVucyBmb3IgY29weS1jb25maWcgdG8g dGhlIGNhbmRpZGF0ZSAoc2V0IHRvIHRyaW0gb3IgZXhwbGljaXQpOyBwcm9wb3NhbDogd2l0aC1k ZWZhdWx0cyBpZ25vcmVkIGZvciB0YXJnZXQ9IGNhbmRpZGF0ZQ0KICAtIEFCIGNvcHktY29uZmln IG9uIGNhbmRpZGF0ZSBzaG91bGQgYmUgaWdub3JlZC4NCiAgLSBBQiBXZSBhbHNvIG5lZWQgdG8g YWRkcmVzcyB0aGUgaXNzdWVzIHdpdGggOnN0YXJ0dXAuDQogIC0gTUIgaGFzIHNpbWlsYXIgcXVl c3Rpb25zIGNvbmNlcm5pbmcgY29weS1jb25maWcgYmV0d2VlbiBkYXRhIHN0b3Jlcw0KICAtIEJM IHNheXMgdGhlIGNhcGFiaWxpdHkgc2hvdWxkIG5vdCBhZmZlY3QgY29weS1jb25maWcgYmV0d2Vl biBkYXRhIHN0b3JlcyBhbmQgdGhlcmUgaXMgYWxyZWFkeSB0ZXh0IGluIHRoZSBkcmFmdA0KICAt IEJXIHBvbGxzIHRoZSByb29tIGFuZCB0aGVyZSBpcyBubyBvYmplY3Rpb24gdG8gbW92ZSB0aGlz IGRvY3VtZW50IHRvIFdHIGxhc3QgY2FsbA0KDQoNCiogUm9idXN0IENvbmZpZ3VyYXRpb24gKEJv YiBDb2xlKQ0KDQogIC0gc2VlIHNsaWRlczogaHR0cDovL3d3dy5pZXRmLm9yZy9wcm9jZWVkaW5n cy83NS9zbGlkZXMvbmV0Y29uZi00LnBkZg0KDQogIC0gU2Vjb25kIGJ1bGxldCBvbiBzbGlkZSAy IHNob3VsZCBiZSAiVmVyaWZpY2F0aW9uIi4NCiAgLSBCVyBhc2tzIGhvdyBtYW55IHBlb3BsZSBo YXZlIHJlYWQgdGhlIGxhdGVzdCBkb2N1bWVudCAoNi03KQ0KICAtIEJXIGFza3MgaG93IG1hbnkg cGVvcGxlIHRoaW5rIHRoYXQgdGhpcyB3b3JrIHNob3VsZCBiZSBpbmNsdWRlZCBpbiB0aGUgV0cg Y2hhcnRlcj8NCiAgLSBhYm91dCAzIHBlb3BsZSBkbw0KICAtIFBTIGtpbmQgb2Ygb2JqZWN0cyBz aW5jZSBoZSBkb2VzIG5vdCBzZWUgdGhlIHZhbHVlIG9mIHB1dHRpbmcgdGhlIHRlc3Qgb24gdGhl IGJveA0KICAtIFBTIFdoeSBzaG91bGQgdGhlIGRldmljZSBydW4gdGVzdHMgaW5zdGVhZCBvZiBt YW5hZ2VyPw0KICAtIEJDIFNvbWV0aW1lcyB0aGUgbWFuYWdlciBtYXkgbm90IGJlIGFibGUgdG8g cnVuIHRoZW0sIGUuZy4gdGhlIGRldmljZSBtYXkgZ2V0IG91dCBvZiByZWFjaC4NCiAgLSBEUiBZ ZXMsIHRoZSBkZXZpY2VzIHNvbWV0aW1lcyBoYXZlIGEgbGV2ZWwgb2YgYXV0b25vbXkuIEJ1dCB3 ZSBuZWVkIHRvIHByb3ZpZGUgYmV0dGVyIHVzZSBjYXNlcy4NCg0KICAtIEpTIHdobyBpcyBwbGFu bmluZyB0byBpbXBsZW1lbnQgdGhpcz8NCiAgLSBBQiBkb2VzIHBsYW4gaXQuDQogIC0gTUIgaGFz IGlzc3VlcyB3aXRoIHNvbWUgZGVzaWduIGRlY2lzaW9ucyB0YWtlbi4gVGhlIHRlc3RzIHNob3Vs ZCBub3QgYmUgdGllZCB0byB0aGUgY29tbWl0IG9wZXJhdGlvbiwgc2VwYXJhdGUgUlBDcyBzaG91 bGQgYmUgdXNlZC4NCiAgLSBBQiBpcyBwbGFubmluZyB0byBpbXBsZW1lbnQgLSBpZiBvbmx5IGFz IGFuIGltcHJvdmVtZW50IHRvIHRoZSBmbGF3ZWQgdGVzdDsgYnV0IHZlcmlmeSB0ZXN0cyBzaG91 bGQgYmUgcnVubmFibGUgbm90IGR1cmluZyBjb21taXQNCiAgLSBBQiBZZXMsIFJQQ3Mgd2lsbCBi ZSB1c2VkLg0KICAtIEJXIE1vcmUgZGlzY3Vzc2lvbiAgaW4gdGhlIG1haWxpbmcgbGlzdCBpcyBu ZWVkZWQgYmVmb3JlIHdlIGNhbiBhY2NlcHQgdGhpcyB3b3JrIGFzIGEgV0cgaXRlbS4NCg0KDQoq IE9wZW4gTWljcm9waG9uZSANCg0KICAtIEJXIGxpc3RlZCBvdGhlciB0b3BpY3MgZm9yIGZ1dHVy ZSBkaXNjdXNzaW9uOg0KICAtIDQ3NDIgY2xhcmlmaWNhdGlvbnMgYXMgYmlzIGRvY3VtZW50Pw0K ICAtIERvIHdlIG5lZWQgdG8gc3BlY2lmeSBhIE5FVENPTkYgZGF0YWJhc2UgYXJjaGl0ZWN0dXJl Pw0KICAtIE5FVENPTkYgQWNjZXNzIGNvbnRyb2wuDQogIC0gVGhlIGNoYWlycyB3aWxsIHB1dCB0 aGUgb3BlbiBtaWMgcXVlc3Rpb25zIHRvIHRoZSBXRyBsaXN0DQoNCiogQWN0b3JzDQoNCiAgLSBB bmR5IEJpZXJtYW4gKEFCKSAodmlhIGphYmJlcikNCiAgLSBNYXJ0aW4gQmpvcmtsdW5kIChNQikN CiAgLSBCb2IgQ29sZSAoQkMpDQogIC0gTWVobWV0IEVyc3VlIChNRSkNCiAgLSBNYXJrIEVsbGlz b24gKE1hcmsgRSkgKE9uIEphYmJlcik6IA0KICAtIFdlcyBIYXJkYWtlciAoV0gpDQogIC0gQmFs YXN6IExlbmd5ZWwgKEJMKQ0KICAtIExhZGlzbGF2IExob3RrYSAoTEwpDQogIC0gRGF2aWQgUGFy dGFpbiAoRFApDQogIC0gRGF2aWQgUmVpZCAoRFIpICh2aWEgamFiYmVyKQ0KICAtIERhbiBSb21h c2NhbnUgKERSKQ0KICAtIEp1ZXJnZW4gU2Nob2Vud2FlbGRlciAoSlMpDQogIC0gUGhpbCBTaGFm ZXIgKFBTKQ0KICAtIEJlcnQgV2lqbmVuIChCVykNCiAgLSBNYXJrIFNjb3R0 ------_=_NextPart_001_01CA16D7.17BAC51E-- From mehmet.ersue@nsn.com Thu Aug 6 13:50: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 247AD3A6DF4 for ; Thu, 6 Aug 2009 13:50:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.254 X-Spam-Level: X-Spam-Status: No, score=-3.254 tagged_above=-999 required=5 tests=[AWL=-0.655, 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 ceeQmKWAi9HF for ; Thu, 6 Aug 2009 13:50:07 -0700 (PDT) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [217.115.75.234]) by core3.amsl.com (Postfix) with ESMTP id 69F433A6D9F for ; Thu, 6 Aug 2009 13:48:37 -0700 (PDT) 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 n76Kmdm4018575 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 6 Aug 2009 22:48:39 +0200 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 n76KmdmD008709; Thu, 6 Aug 2009 22:48:39 +0200 Received: from DEMUEXC005.nsn-intra.net ([10.150.128.17]) by demuexc024.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Thu, 6 Aug 2009 22:48:39 +0200 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, 6 Aug 2009 22:48:37 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Netconf] WGLC: draft-ietf-netconf-with-defaults-02 Thread-Index: AcoWyjBTXdBTFHvaSjmCPRVz/EzYqgABb2sQAAHOnQA= From: "Ersue, Mehmet (NSN - DE/Munich)" To: "Juergen Schoenwaelder" , X-OriginalArrivalTime: 06 Aug 2009 20:48:39.0010 (UTC) FILETIME=[4680B420:01CA16D7] Subject: [Netconf] FW: WGLC: draft-ietf-netconf-with-defaults-02 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, 06 Aug 2009 20:50:08 -0000 [splitting the thread into two parts] > From: ext Juergen Schoenwaelder Thursday, August 06, 2009 9:15 PM >=20 > On Thu, Aug 06, 2009 at 05:55:26PM +0200, Ersue, Mehmet (NSN=20 > - DE/Munich) wrote: > =20 ...=20 > > I agree that if the default is '3' and the value is '3', it is > > considered to contain the default, regardless of how it > > was created. >=20 > This is one interpretation, but not all systems have this > interpretation. >=20 > > The draft does not specify explicitly set (default) data > > clearly. >=20 > This is the interpretation where 3 is the default value but there was > an explicit management operation to set the value to 3 and thus this > value now becomes part of the config (because it was explicitely set, > not because of the value itself). >=20 > > How do we handle non-default values which have been > > set explicitely, where the default is '3' but the value is > > _not_ '3' ? Are they suppressed too? >=20 > In this model, everything explicitly set is config data - the value > does not matter. It matters that the value was explicitely set. Exactly. But in Chapter 1.1.2. the definition of the term=20 "Explicitly set default data" focuses only on: "Data that=20 is explicitly set by the NETCONF client to its default value." I would rather add here what you are saying:=20 "Everything explicitly set is config data independently of the=20 fact whether it's value matches the default value or not." The statement "Some servers MAY treat explicitly=20 set default data as simple default data, as they may=20 not be able to differentiate between them." is somehow=20 misleading. To get it free of confusion I would add to the definition of the basic mode "explicit" in chapter 1.2.:=20 "An agent which supports the basic mode "explicit" MUST=20 support the recognition of explicitly defined data." Mehmet > We probably need some more text plus an example to describe these > three models more clearly. > >=20 > /js >=20 > --=20 > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany > Fax: +49 421 200 3103 >=20 From Washam.Fan@huaweisymantec.com Thu Aug 6 23:14: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 5E98A3A6B3D; Thu, 6 Aug 2009 23:14:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.202 X-Spam-Level: * X-Spam-Status: No, score=1.202 tagged_above=-999 required=5 tests=[AWL=-1.503, BAYES_50=0.001, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_43=0.6, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WsVUIN8Gs6oU; Thu, 6 Aug 2009 23:14:38 -0700 (PDT) Received: from mta2.huaweisymantec.com (unknown [218.17.155.15]) by core3.amsl.com (Postfix) with ESMTP id 1CC2B28C0F5; Thu, 6 Aug 2009 23:14:24 -0700 (PDT) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-disposition: inline Content-type: text/plain; charset=us-ascii Received: from hstml01-in.huaweisymantec.com ([172.26.3.42]) by hstga02-in.huaweisymantec.com (Sun Java(tm) System Messaging Server 6.3-8.03 (built Apr 24 2009; 32bit)) with ESMTP id <0KNZ001TDTBS3J30@hstga02-in.huaweisymantec.com>; Fri, 07 Aug 2009 14:14:16 +0800 (CST) Received: from huaweisymantec.com ([127.0.0.1]) by hstml01-in.huaweisymantec.com (Sun Java(tm) System Messaging Server 6.3-8.03 (built Apr 24 2009; 32bit)) with ESMTP id <0KNZ00LL6TBSMM10@hstml01-in.huaweisymantec.com>; Fri, 07 Aug 2009 14:14:16 +0800 (CST) Received: from [10.27.154.141] by hstml01-in.huaweisymantec.com (mshttpd); Fri, 07 Aug 2009 14:14:16 +0800 From: WashamFan To: Balazs Lengyel Message-id: Date: Fri, 07 Aug 2009 14:14:16 +0800 X-Mailer: Sun Java(tm) System Messenger Express 6.3-8.03 (built Apr 24 2009; 32bit) Content-language: en X-Accept-Language: en Priority: normal In-reply-to: <4A7972DF.7000202@ericsson.com> References: <20090802171214.428EB3A6995@core3.amsl.com> <4A7972DF.7000202@ericsson.com> Cc: netconf mailing list , draft-ietf-netconf-partial-lock@tools.ietf.org, Adrian Farrel , netconf-chairs@tools.ietf.org, iesg@ietf.org Subject: Re: [Netconf] DISCUSS: draft-ietf-netconf-partial-lock 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, 07 Aug 2009 06:14:39 -0000 > Adrian Farrel wrote: > > Discuss: > > > > If I read it right, in 2.4.1 where you have... > > A partial lock operation MUST fail if: > > > > o Any NETCONF session (including the current session) owns the > > global lock on any target datastore. > > ...you are saying that if I want to drop down from the global lock > to > > a partial lock, I must first unlock everything and then take up the > > partial lock. Of course, this opens up a small window, so the > > application is encouraged (in order to not open the window) to retain > > the global lock longer than needed. Did you consider letting a session > > take up a partial lock and then release the global lock (in exactly > the > > way overlapping partial locks are allowed at the same time - since > the > > global lock is only a special case of a partial lock!) > > > > Ditto the reverse case. That is, why can't a session holding a partial > > lock increase this to the global lock without first releaseing the > > > partial lock (and opening a window). This is less of an issue because > > the session could grab a second, overlapping partial lock that includes > > every node. That might be messy, but achieves the desired function. > > BALAZS: The exact same question was debated in the WG with the conclusion: > - For compatibility reasons don't change how the (global) lock works > in rfc4741. There it says: > "An attempt to lock the configuration MUST fail if an existing > session or other entity holds a lock on any portion of the lock > target." > This means going from a partial to a global lock is not allowed > without releasing the partial lock. > > - Don't allow a session to hold both a partial and global lock at the > same time. There is no > real need and this method makes implementation more simple. If we > don't allow partial lock and > later the global lock(see above), allowing global and afterwards a > partial lock would be confusing. > The correct procedure should be that the user starts with partial > locking immediately, in > extreme with a partial lock that covers the entire datastore. This > way he can reduce the scope > of partial locking without any unlocked interval. A partial lock covering the entire datastore can be treated as a global lock allowing overlapping locks. Can I understand in this way? washam From j.schoenwaelder@jacobs-university.de Fri Aug 7 02:32: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 78FD13A6E9E for ; Fri, 7 Aug 2009 02:32:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.203 X-Spam-Level: X-Spam-Status: No, score=-2.203 tagged_above=-999 required=5 tests=[AWL=0.046, 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 5ivsIi8-opLp for ; Fri, 7 Aug 2009 02:32:04 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 4E9B73A6A5A for ; Fri, 7 Aug 2009 02:32:04 -0700 (PDT) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id DDD02C0091; Fri, 7 Aug 2009 11:32:06 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius4.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id gpdhZ10iZ2jk; Fri, 7 Aug 2009 11:32:05 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 6B97FC008F; Fri, 7 Aug 2009 11:32:05 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 3732CB7E25E; Fri, 7 Aug 2009 11:32:04 +0200 (CEST) Date: Fri, 7 Aug 2009 11:32:04 +0200 From: Juergen Schoenwaelder To: Andy Bierman Message-ID: <20090807093204.GA1827@elstar.local> Mail-Followup-To: Andy Bierman , Balazs Lengyel , netconf mailing list References: <4A7984EA.4000703@ericsson.com> <20090806111305.GA3340@elstar.local> <4A7AF036.30400@netconfcentral.com> <20090806151832.GA1013@elstar.local> <4A7AFF46.8040708@netconfcentral.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4A7AFF46.8040708@netconfcentral.com> User-Agent: Mutt/1.5.19 (2009-01-05) Cc: netconf mailing list Subject: Re: [Netconf] [Fwd: New Version Notification for draft-ietf-netconf-with-defaults-03] 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, 07 Aug 2009 09:32:05 -0000 On Thu, Aug 06, 2009 at 06:05:26PM +0200, Andy Bierman wrote: > I object to extensions that every YANG tool must support. > What's the point of that? Make it a keyword. > > So let's add capability-stmt as an optional child of feature-stmt: > > feature candidate { > description > "NETCONF :candidate capability; > If the agent advertises the :candidate > capability for a session, then this feature must > also be enabled for that session. Otherwise, > this feature must not be enabled."; > reference "RFC XXXX, section 8.3."; > capability "urn:ietf:params:netconf:capability:candidate:1.0"; > } > > The capability-stmt is used to indicate that a legacy NETCONF > capability URI is mapped to this YANG feature. Every YANG compiler > MUST support it (opposite of extensions) so a developer can rely on it. I object to this proposal since capabilities are only used for backwards compatible protocol extensions and not for data models. > > NETCONF and NETCONF extensions do not overload things in wired > > ways. The with-default says there is a parameter attached to indicate > > the default default handling and this is not expressed using features. > > So please fix this. > > I prefer to make with-defaults wait until YANG is done, > and ONLY have a YANG module with read-only 'basic' and 'extended' > leafs to indicate the agent's default handling behavior. > > The use of a capability instead of a YANG data model is a total hack. I prefer a solution where NETCONF servers announce their default handling behaviour in the message; I do not want to have to issue a first to figure out how the server behaves. I think this is also inline with the way all other data model specific features are announced in NETCONF. /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 Fri Aug 7 06:14: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 6BCA73A6B18 for ; Fri, 7 Aug 2009 06:14:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.488 X-Spam-Level: X-Spam-Status: No, score=-2.488 tagged_above=-999 required=5 tests=[AWL=0.111, 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 aQ76juIyf7MA for ; Fri, 7 Aug 2009 06:14:57 -0700 (PDT) Received: from n15a.bullet.mail.mud.yahoo.com (n15a.bullet.mail.mud.yahoo.com [68.142.207.125]) by core3.amsl.com (Postfix) with SMTP id 6C5213A6859 for ; Fri, 7 Aug 2009 06:14:57 -0700 (PDT) Received: from [209.191.108.96] by n15.bullet.mail.mud.yahoo.com with NNFMP; 07 Aug 2009 13:14:58 -0000 Received: from [68.142.201.247] by t3.bullet.mud.yahoo.com with NNFMP; 07 Aug 2009 13:14:58 -0000 Received: from [127.0.0.1] by omp408.mail.mud.yahoo.com with NNFMP; 07 Aug 2009 13:14:58 -0000 X-Yahoo-Newman-Id: 935566.80268.bm@omp408.mail.mud.yahoo.com Received: (qmail 11065 invoked from network); 7 Aug 2009 13:14:58 -0000 Received: from unknown (HELO ?192.168.0.10?) (andy@67.125.157.61 with plain) by smtp106.sbc.mail.sp1.yahoo.com with SMTP; 7 Aug 2009 13:14:58 -0000 X-YMail-OSG: 4cTyG9sVM1katbThVgilLS743l4aZ87FOwXzeUomjCN4DRzYOndCszjK69yl8lORBc34.RTpn24pN5T.l1l07d1WIYcVJqH.zCb8qIYh3wwaGDxkJTgnxDmH4VgeJ2fxMh8qHB2Y.bzbQFbZKozSddRuIMmtRP8Y4Qqx6Zc3urQpoCY0q0NsW9OC1iuyD4QIxuJoIgjQVv6WDAnNNuKCeueG0NvWEWbxZ0izYEGSW9rwwjM3rOF.YCnuysusiZE2fSKfY7xECoP4UfgcRQoiphDBD6NuSg9bPHHI9LUckkVxpKMFroI- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4A7C2892.9030308@netconfcentral.com> Date: Fri, 07 Aug 2009 06:13:54 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.22 (X11/20090608) MIME-Version: 1.0 To: Andy Bierman , Balazs Lengyel , netconf mailing list References: <4A7984EA.4000703@ericsson.com> <20090806111305.GA3340@elstar.local> <4A7AF036.30400@netconfcentral.com> <20090806151832.GA1013@elstar.local> <4A7AFF46.8040708@netconfcentral.com> <20090807093204.GA1827@elstar.local> In-Reply-To: <20090807093204.GA1827@elstar.local> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [Netconf] [Fwd: New Version Notification for draft-ietf-netconf-with-defaults-03] 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, 07 Aug 2009 13:14:58 -0000 Juergen Schoenwaelder wrote: > On Thu, Aug 06, 2009 at 06:05:26PM +0200, Andy Bierman wrote: > >> I object to extensions that every YANG tool must support. >> What's the point of that? Make it a keyword. >> >> So let's add capability-stmt as an optional child of feature-stmt: >> >> feature candidate { >> description >> "NETCONF :candidate capability; >> If the agent advertises the :candidate >> capability for a session, then this feature must >> also be enabled for that session. Otherwise, >> this feature must not be enabled."; >> reference "RFC XXXX, section 8.3."; >> capability "urn:ietf:params:netconf:capability:candidate:1.0"; >> } >> >> The capability-stmt is used to indicate that a legacy NETCONF >> capability URI is mapped to this YANG feature. Every YANG compiler >> MUST support it (opposite of extensions) so a developer can rely on it. > > I object to this proposal since capabilities are only used for > backwards compatible protocol extensions and not for data models. > OK -- let's leave the whole thing out. It is not important enough to worry about. >>> NETCONF and NETCONF extensions do not overload things in wired >>> ways. The with-default says there is a parameter attached to indicate >>> the default default handling and this is not expressed using features. >>> So please fix this. >> I prefer to make with-defaults wait until YANG is done, >> and ONLY have a YANG module with read-only 'basic' and 'extended' >> leafs to indicate the agent's default handling behavior. >> >> The use of a capability instead of a YANG data model is a total hack. > > I prefer a solution where NETCONF servers announce their default > handling behaviour in the message; I do not want to have to > issue a first to figure out how the server behaves. I think this > is also inline with the way all other data model specific features are > announced in NETCONF. > This leads to 1-off coding for every single parameter since they are all encoded differently, and the syntax is only explained in a description clause. I prefer consistent, easy-to-use management operations that can be used at any time. I prefer to have this sort of device capability info available in the data model, so must/when/select expressions can reference it as needed. > /js > Andy From j.schoenwaelder@jacobs-university.de Fri Aug 7 07:10: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 683A128C1DC for ; Fri, 7 Aug 2009 07:10:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.204 X-Spam-Level: X-Spam-Status: No, score=-2.204 tagged_above=-999 required=5 tests=[AWL=0.045, 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 2xwhFvtZ7O35 for ; Fri, 7 Aug 2009 07:10:54 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 2F3AB28C1A7 for ; Fri, 7 Aug 2009 07:10:54 -0700 (PDT) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 2943CC0099; Fri, 7 Aug 2009 16:10:57 +0200 (CEST) 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 daKqale5zDZq; Fri, 7 Aug 2009 16:10:56 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 9F333C0095; Fri, 7 Aug 2009 16:10:55 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 5532EB7E731; Fri, 7 Aug 2009 16:10:54 +0200 (CEST) Date: Fri, 7 Aug 2009 16:10:54 +0200 From: Juergen Schoenwaelder To: Andy Bierman Message-ID: <20090807141054.GC2039@elstar.local> Mail-Followup-To: Andy Bierman , Balazs Lengyel , netconf mailing list References: <4A7984EA.4000703@ericsson.com> <20090806111305.GA3340@elstar.local> <4A7AF036.30400@netconfcentral.com> <20090806151832.GA1013@elstar.local> <4A7AFF46.8040708@netconfcentral.com> <20090807093204.GA1827@elstar.local> <4A7C2892.9030308@netconfcentral.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4A7C2892.9030308@netconfcentral.com> User-Agent: Mutt/1.5.19 (2009-01-05) Cc: netconf mailing list Subject: Re: [Netconf] [Fwd: New Version Notification for draft-ietf-netconf-with-defaults-03] 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, 07 Aug 2009 14:10:55 -0000 On Fri, Aug 07, 2009 at 03:13:54PM +0200, Andy Bierman wrote: > >>> NETCONF and NETCONF extensions do not overload things in wired > >>> ways. The with-default says there is a parameter attached to indicate > >>> the default default handling and this is not expressed using features. > >>> So please fix this. > >> I prefer to make with-defaults wait until YANG is done, > >> and ONLY have a YANG module with read-only 'basic' and 'extended' > >> leafs to indicate the agent's default handling behavior. > >> > >> The use of a capability instead of a YANG data model is a total hack. > > > > I prefer a solution where NETCONF servers announce their default > > handling behaviour in the message; I do not want to have to > > issue a first to figure out how the server behaves. I think this > > is also inline with the way all other data model specific features are > > announced in NETCONF. > > This leads to 1-off coding for every single parameter since they > are all encoded differently, and the syntax is only explained > in a description clause. I prefer consistent, easy-to-use management > operations that can be used at any time. Features are announced in a consistent way. The -with-defaults ID currently cooks its own mechanis and I agree this is bad. Thats why I suggest to use features to announce the default default handling. > I prefer to have this > sort of device capability info available in the data model, > so must/when/select expressions can reference it as needed. I prefer to know after the exchange to what type of server I am talking to instead of first having to do an additional and then to merge the information and the response of the in order to know what type of server I am talking with. /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 Fri Aug 7 07:18: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 F205F28C1D0 for ; Fri, 7 Aug 2009 07:18:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.917 X-Spam-Level: X-Spam-Status: No, score=-2.917 tagged_above=-999 required=5 tests=[AWL=-0.918, BAYES_00=-2.599, J_CHICKENPOX_210=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 xI-8ZsP5ifat for ; Fri, 7 Aug 2009 07:18:07 -0700 (PDT) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [217.115.75.234]) by core3.amsl.com (Postfix) with ESMTP id BB2AC28C1EC for ; Fri, 7 Aug 2009 07:18:06 -0700 (PDT) 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 n77EI7nq020618 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 7 Aug 2009 16:18:07 +0200 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 n77EI7ls013684; Fri, 7 Aug 2009 16:18:07 +0200 Received: from DEMUEXC005.nsn-intra.net ([10.150.128.17]) by demuexc024.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Fri, 7 Aug 2009 16:18:07 +0200 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: Fri, 7 Aug 2009 16:18:05 +0200 Message-ID: In-Reply-To: <20090806111305.GA3340@elstar.local> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Netconf] [Fwd: New Version Notificationfor draft-ietf-netconf-with-defaults-03] Thread-Index: AcoWhuTwgVnxr5tJTGyIMWqwaZljDwA4kYow References: <4A7984EA.4000703@ericsson.com> <20090806111305.GA3340@elstar.local> From: "Ersue, Mehmet (NSN - DE/Munich)" To: "Juergen Schoenwaelder" , "Balazs Lengyel" X-OriginalArrivalTime: 07 Aug 2009 14:18:07.0161 (UTC) FILETIME=[E2720A90:01CA1769] Cc: netconf mailing list Subject: Re: [Netconf] [Fwd: New Version Notificationfor draft-ietf-netconf-with-defaults-03] 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, 07 Aug 2009 14:18:08 -0000 > I would prefer if this document would move along with RFC4741bis so > that we can make the YANG normative. Speaking as a contributor: I support With-default draft moving along with RFC4741bis=20 and YANG documents and having the With-default YAM as normative.=20 Mehmet =20 > -----Original Message----- > From: netconf-bounces@ietf.org=20 > [mailto:netconf-bounces@ietf.org] On Behalf Of ext Juergen=20 > Schoenwaelder > Sent: Thursday, August 06, 2009 1:13 PM > To: Balazs Lengyel > Cc: netconf mailing list > Subject: Re: [Netconf] [Fwd: New Version Notificationfor=20 > draft-ietf-netconf-with-defaults-03] >=20 > On Wed, Aug 05, 2009 at 03:11:06PM +0200, Balazs Lengyel wrote: >=20 > > Sorry for doing this in the middle of WG Last call, but I posted a > > new draft. I realized that it would be important to include the > > non-normative YAM in the WG last call. >=20 > Here is my review of the -03 version of this document. The comments > are in document order. >=20 > s /often needs a single/needs a single/ >=20 > The text talks about "controls whether default data is part of NETCONF > messages"; I would prefer if the text would say that it > "extends the NETCONF , , and operations > with an additional parameter that allows the NETCONF client to control > whether default data is returned in the result. I think we should take > the layered architecture of NETCONF serious. This change affects > several places of the document since it should nowhere talk about > messages. >=20 > I am not sure how we deal with capabilities within YANG. What about > having the ietf-netconf.yang introduce a nc:capability extension > statement that can be used to define the capability URI for a YANG > feature, just of usage to describe NETCONF protocol extensions? I > am thinking of >=20 > extension nc:capability { > description > "This extension is used to define capability URIs in NETCONF > protocol modules written in YANG. It is not supposed to be > used outside of NETCONF protocol specifications."; > argument "uri"; > } >=20 > This way, the features used to define protocol capabilities could > indicate the capability URI associated with a protocol "feature". I > also note that the with-defaults ID adds special parameters to the > capability URI which is something we do not have special support for > in YANG - think the YANG approach would be to define feature and to > use the feature announcement mechanism. Why do we do something special > here? >=20 > I suggest to get rid of the subsubsection headlines 1.1.1 and 1.1.2; > just have a section 1.1. >=20 > s/A NETCONF servers/A NETCONF server/ >=20 > s/parameter Possible/parameter. Possible/ >=20 > s/return default data in the NETCONF =20 > message/return default data/ >=20 > In section 2.5, be explicit which error is returned if a client sends > a with-default value the server does not support. >=20 > In the YANG module s/with-defaults-mode-type/with-defaults-mode/ and I > would probably have choosen the prefix nc-wd instead of nwd. >=20 > I would prefer if this document would move along with RFC4741bis so > that we can make the YANG normative. >=20 > /js >=20 > --=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 >=20 From j.schoenwaelder@jacobs-university.de Fri Aug 7 07:21: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 1BBEA3A6CC7 for ; Fri, 7 Aug 2009 07:21:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.204 X-Spam-Level: X-Spam-Status: No, score=-2.204 tagged_above=-999 required=5 tests=[AWL=0.045, 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 6AR4DRa7e9gO for ; Fri, 7 Aug 2009 07:21:52 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id A9A2C3A6A73 for ; Fri, 7 Aug 2009 07:21:51 -0700 (PDT) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id A4E2CC0097; Fri, 7 Aug 2009 16:21:54 +0200 (CEST) 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 2FRwohSYGQ4P; Fri, 7 Aug 2009 16:21:54 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id EE949C0095; Fri, 7 Aug 2009 16:21:53 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id DC886B7E8A1; Fri, 7 Aug 2009 16:21:52 +0200 (CEST) Date: Fri, 7 Aug 2009 16:21:52 +0200 From: Juergen Schoenwaelder To: "Ersue, Mehmet (NSN - DE/Munich)" Message-ID: <20090807142152.GA2668@elstar.local> Mail-Followup-To: "Ersue, Mehmet (NSN - DE/Munich)" , Balazs Lengyel , netconf mailing list References: <4A7984EA.4000703@ericsson.com> <20090806111305.GA3340@elstar.local> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.19 (2009-01-05) Cc: netconf mailing list Subject: Re: [Netconf] [Fwd: New Version Notificationfor draft-ietf-netconf-with-defaults-03] 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, 07 Aug 2009 14:21:53 -0000 On Fri, Aug 07, 2009 at 04:18:05PM +0200, Ersue, Mehmet (NSN - DE/Munich) wrote: > > > I would prefer if this document would move along with RFC4741bis so > > that we can make the YANG normative. > > Speaking as a contributor: > I support With-default draft moving along with RFC4741bis > and YANG documents and having the With-default YAM as normative. I also prefer to move to normative YANG in both documents. /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 Fri Aug 7 07:33: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 ED1D93A6EC4 for ; Fri, 7 Aug 2009 07:33:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.539 X-Spam-Level: X-Spam-Status: No, score=-6.539 tagged_above=-999 required=5 tests=[AWL=0.060, 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 HNLLNBcYynfz for ; Fri, 7 Aug 2009 07:33:32 -0700 (PDT) Received: from exprod7og111.obsmtp.com (exprod7og111.obsmtp.com [64.18.2.175]) by core3.amsl.com (Postfix) with ESMTP id 2B2B828C1D7 for ; Fri, 7 Aug 2009 07:33:32 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob111.postini.com ([64.18.6.12]) with SMTP ID DSNKSnw7Ogu2+1u2Q+DfqrIMt13tZg1kTNsn@postini.com; Fri, 07 Aug 2009 07:33:35 PDT 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; Fri, 7 Aug 2009 07:25:41 -0700 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, 7 Aug 2009 07:25:41 -0700 Received: from emailsmtp56.jnpr.net ([172.24.60.77]) by p-emlb02-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Fri, 7 Aug 2009 07:25:40 -0700 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp56.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Fri, 7 Aug 2009 07:25:39 -0700 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 n77EPdd93417; Fri, 7 Aug 2009 07:25:39 -0700 (PDT) (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 n77EE1ha029875; Fri, 7 Aug 2009 14:14:01 GMT (envelope-from phil@idle.juniper.net) Message-ID: <200908071414.n77EE1ha029875@idle.juniper.net> To: Juergen Schoenwaelder In-Reply-To: <20090807142152.GA2668@elstar.local> Date: Fri, 7 Aug 2009 10:14:00 -0400 From: Phil Shafer X-OriginalArrivalTime: 07 Aug 2009 14:25:39.0921 (UTC) FILETIME=[F04FBC10:01CA176A] MIME-Version: 1.0 Content-Type: text/plain Cc: netconf mailing list Subject: Re: [Netconf] [Fwd: New Version Notificationfor draft-ietf-netconf-with-defaults-03] 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, 07 Aug 2009 14:33:33 -0000 Juergen Schoenwaelder writes: >I also prefer to move to normative YANG in both documents. I suggested this also for the monitoring draft, and still do. If YANG is the future, we shouldn't be afraid of depending on it, even if it means a small delay. Thanks, Phil From mehmet.ersue@nsn.com Fri Aug 7 07:39: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 F15113A6EE9 for ; Fri, 7 Aug 2009 07:39:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.169 X-Spam-Level: X-Spam-Status: No, score=-5.169 tagged_above=-999 required=5 tests=[AWL=1.430, 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 QvP7qhcsZTWE for ; Fri, 7 Aug 2009 07:39:44 -0700 (PDT) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [217.115.75.233]) by core3.amsl.com (Postfix) with ESMTP id CE4593A6882 for ; Fri, 7 Aug 2009 07:39:38 -0700 (PDT) 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 n77Edd5r018522 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 7 Aug 2009 16:39:39 +0200 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 n77Eddpe027081; Fri, 7 Aug 2009 16:39:39 +0200 Received: from DEMUEXC005.nsn-intra.net ([10.150.128.17]) by demuexc023.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Fri, 7 Aug 2009 16:39:39 +0200 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: Fri, 7 Aug 2009 16:39:37 +0200 Message-ID: In-Reply-To: <20090807142152.GA2668@elstar.local> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Netconf] [Fwd: New Version Notificationfordraft-ietf-netconf-with-defaults-03] Thread-Index: AcoXamqT1vgr4ZJiQQ6LuCA55NnE4gAAY0jw References: <4A7984EA.4000703@ericsson.com> <20090806111305.GA3340@elstar.local> <20090807142152.GA2668@elstar.local> From: "Ersue, Mehmet (NSN - DE/Munich)" To: "Juergen Schoenwaelder" X-OriginalArrivalTime: 07 Aug 2009 14:39:39.0212 (UTC) FILETIME=[E49160C0:01CA176C] Cc: netconf mailing list Subject: Re: [Netconf] [Fwd: New Version Notificationfordraft-ietf-netconf-with-defaults-03] 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, 07 Aug 2009 14:39:45 -0000 I think we will have still a few things to do for 4741bis through August and probably September. We should also think on getting the text more clear by avoiding conflicts with XSD. OTOH I'm keen of getting the documents published soon,=20 which are ready to publish and for which we decided to start the publishing process already. Mehmet =20 > -----Original Message----- > From: ext Juergen Schoenwaelder=20 > [mailto:j.schoenwaelder@jacobs-university.de]=20 > Sent: Friday, August 07, 2009 4:22 PM > To: Ersue, Mehmet (NSN - DE/Munich) > Cc: Balazs Lengyel; netconf mailing list > Subject: Re: [Netconf] [Fwd: New Version=20 > Notificationfordraft-ietf-netconf-with-defaults-03] >=20 > On Fri, Aug 07, 2009 at 04:18:05PM +0200, Ersue, Mehmet (NSN=20 > - DE/Munich) wrote: > >=20 > > > I would prefer if this document would move along with=20 > RFC4741bis so > > > that we can make the YANG normative. > >=20 > > Speaking as a contributor: > > I support With-default draft moving along with RFC4741bis=20 > > and YANG documents and having the With-default YAM as normative.=20 >=20 > I also prefer to move to normative YANG in both documents. >=20 > /js >=20 > --=20 > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany > Fax: +49 421 200 3103 >=20 From j.schoenwaelder@jacobs-university.de Fri Aug 7 07:45: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 AF67B28C169 for ; Fri, 7 Aug 2009 07:45:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.205 X-Spam-Level: X-Spam-Status: No, score=-2.205 tagged_above=-999 required=5 tests=[AWL=0.044, 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 knXa2OYFzks2 for ; Fri, 7 Aug 2009 07:45:05 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 4D5A33A6C42 for ; Fri, 7 Aug 2009 07:44:51 -0700 (PDT) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id ED208C0097 for ; Fri, 7 Aug 2009 16:44:49 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius1.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 3YhCvqdpTw3x; Fri, 7 Aug 2009 16:44:49 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 4EA91C0099; Fri, 7 Aug 2009 16:44:49 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 4CBFAB7E922; Fri, 7 Aug 2009 16:44:48 +0200 (CEST) Date: Fri, 7 Aug 2009 16:44:48 +0200 From: Juergen Schoenwaelder To: netconf@ietf.org Message-ID: <20090807144448.GB2668@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.19 (2009-01-05) Subject: [Netconf] ip address types in the monitoring draft 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, 07 Aug 2009 14:45:05 -0000 Hi, I checked the IPv4 and IPv6 address types in the XSD and in yang-types and they are both different. This means that the sourceHost accepts slightly different things if you compare the XSD and YANG versions of the data models. Now, the IPv4 pattern can be made the same by copying (and hoping the yang-types patter won't change anymore). For the IPv6 pattern, things are slightly more complicated since the YANG module makes use of the YANG feature to have multiple pattern; this would translate into an additional intermediate type for the XSD schema. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From j.schoenwaelder@jacobs-university.de Fri Aug 7 07:46: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 B33703A6910 for ; Fri, 7 Aug 2009 07:46:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.205 X-Spam-Level: X-Spam-Status: No, score=-2.205 tagged_above=-999 required=5 tests=[AWL=0.044, 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 LX7BJ0EDkF4V for ; Fri, 7 Aug 2009 07:46:30 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id EF7673A68BB for ; Fri, 7 Aug 2009 07:46:29 -0700 (PDT) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id ED101C0097 for ; Fri, 7 Aug 2009 16:46:32 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius1.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id dp0hens8JfRs; Fri, 7 Aug 2009 16:46:32 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 4A51DC0095; Fri, 7 Aug 2009 16:46:32 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 40FB4B7E956; Fri, 7 Aug 2009 16:46:31 +0200 (CEST) Date: Fri, 7 Aug 2009 16:46:31 +0200 From: Juergen Schoenwaelder To: netconf@ietf.org Message-ID: <20090807144631.GC2668@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.19 (2009-01-05) Subject: [Netconf] yang document consistency 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, 07 Aug 2009 14:46:30 -0000 While checking the IP address pattern in the monitoring draft, I realized that the monitoring document uses a writing style for identifiers which is different from all the other YANG documents we have in the making so far and I personally would prefer commonality. I also noted names such as NETCONFDatastoreType for a grouping, which I think is misleading - it is not a type. I also would prefer a different suggested prefix, e.g. nc-s (see also my suggestion for nc-wd for the with-defaults document), so that we have consistent prefixes for all NETCONF related data models. Perhaps we need to establish some YANG doctors at some point in time to help in making documents consistent. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From j.schoenwaelder@jacobs-university.de Fri Aug 7 07:50: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 ADD653A68BB for ; Fri, 7 Aug 2009 07:50:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.206 X-Spam-Level: X-Spam-Status: No, score=-2.206 tagged_above=-999 required=5 tests=[AWL=0.043, 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 FOvDVUer+SqA for ; Fri, 7 Aug 2009 07:50:09 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id EF52F3A6892 for ; Fri, 7 Aug 2009 07:50:08 -0700 (PDT) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 190A8C0097; Fri, 7 Aug 2009 16:50:11 +0200 (CEST) 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 49nTnn+bJnkk; Fri, 7 Aug 2009 16:50:10 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 7B44AC0095; Fri, 7 Aug 2009 16:50:10 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 780B9B7E9D0; Fri, 7 Aug 2009 16:50:09 +0200 (CEST) Date: Fri, 7 Aug 2009 16:50:09 +0200 From: Juergen Schoenwaelder To: Phil Shafer Message-ID: <20090807145009.GD2668@elstar.local> Mail-Followup-To: Phil Shafer , "Ersue, Mehmet (NSN - DE/Munich)" , netconf mailing list References: <20090807142152.GA2668@elstar.local> <200908071414.n77EE1ha029875@idle.juniper.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200908071414.n77EE1ha029875@idle.juniper.net> User-Agent: Mutt/1.5.19 (2009-01-05) Cc: netconf mailing list Subject: Re: [Netconf] [Fwd: New Version Notificationfor draft-ietf-netconf-with-defaults-03] 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, 07 Aug 2009 14:50:09 -0000 On Fri, Aug 07, 2009 at 04:14:00PM +0200, Phil Shafer wrote: > Juergen Schoenwaelder writes: > >I also prefer to move to normative YANG in both documents. > > I suggested this also for the monitoring draft, and still do. > If YANG is the future, we shouldn't be afraid of depending on > it, even if it means a small delay. I am also in favour of that - and this would solve the IP address issue. ;-) /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 Fri Aug 7 08:18:35 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 014F93A6B18 for ; Fri, 7 Aug 2009 08:18:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.323 X-Spam-Level: X-Spam-Status: No, score=-2.323 tagged_above=-999 required=5 tests=[AWL=-0.058, 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 7fvfQK+Si55R for ; Fri, 7 Aug 2009 08:18:34 -0700 (PDT) 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 4A5393A6A89 for ; Fri, 7 Aug 2009 08:18:34 -0700 (PDT) Received: (qmail 20020 invoked from network); 7 Aug 2009 15:18:34 -0000 Received: from unknown (HELO ?192.168.0.10?) (andy@67.125.157.61 with plain) by smtp125.sbc.mail.sp1.yahoo.com with SMTP; 7 Aug 2009 15:18:34 -0000 X-YMail-OSG: sZXK0LkVM1leZg41JhiPLocd6VpyhwuXgpAJPNl826gEWTu4ePkbSKR9L8uA2zLKWI5b48pab.X.r68MRTBRIqmH4ljgnXMMqyhKo2MNKfApzkiewJI_WzhhdB8K2U1wDuMOx62txru2btw7S0V2A0g01JvTJMm_io0sFKQZv0jG6bWZnbp5VpyrCjwn0MuFYeauOGDzwt.6gGJqp8FYwj4J_ooH.RguRu.MBDIyLm6vooO6hONH2AepNGkDktMOpc7HlTGwFfSOl8aRAA8CArAhOjBItoZD.X8fLJ3QEhsy3cxti7Hk3DnDYQagyqpmTJo- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4A7C4604.5050008@netconfcentral.com> Date: Fri, 07 Aug 2009 08:19:32 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.22 (X11/20090608) MIME-Version: 1.0 To: Randy Presuhn References: <4A7AFA9B.8030504@netconfcentral.com> <002701ca16bb$90da4700$6801a8c0@oemcomputer> In-Reply-To: <002701ca16bb$90da4700$6801a8c0@oemcomputer> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: NETCONF Subject: Re: [Netconf] too many optional components? 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, 07 Aug 2009 15:18:35 -0000 Randy Presuhn wrote: > Hi Andy - > > I think you're absolutely right on this. And it's not just the > capabilities, but also the way module versioning and reuse > will work that have this property. I'm soooo glad I don't > have to implement this. :-) > Hi Randy, Sorry for posting your private reply to the WG, but you have a lot of NM and standards experience across several SDOs and decades, so I think your perspective and insights on interoperability need to be considered by the WG. The intent is that many people will attempt implementations. > Randy Andy > > ----- Original Message ----- > From: "Andy Bierman" > To: "NETCONF" > Sent: Thursday, August 06, 2009 8:45 AM > Subject: [Netconf] too many optional components? > > >> Hi, >> >> I am starting to wonder if so many interacting optional components >> in the NETCONF protocol is such a good idea. >> >> We are still early in the technology curve with NETCONF, >> and already it is obvious that just the variants >> from the 10 or so capabilities already defined are leading >> to lots of interoperability issues. >> >> The interactions grow with N^^2, so 20 capabilities will >> be 4 times worse, not twice as bad as now. Every new NETCONF >> draft introduces at least 1 (sometimes 2) new capabilities, >> and we are on track to reach 20 capabilities in less than 3 years. >> >> Assuming a 15 - 20 year standards track lifetime, we could have >> 100,000 valid variants of the NETCONF standard by the >> time we're done. That's great for an agent developer, >> who just wants to use NETCONF buffet-style. >> But it looks like 'worst nightmare ever' to an NMS developer >> who has to support lots of different agents. >> >> >> Andy >> _______________________________________________ >> Netconf mailing list >> Netconf@ietf.org >> https://www.ietf.org/mailman/listinfo/netconf > > From cfinss@dial.pipex.com Fri Aug 7 11:28: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 005553A67F4 for ; Fri, 7 Aug 2009 11:28:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.308 X-Spam-Level: X-Spam-Status: No, score=-2.308 tagged_above=-999 required=5 tests=[AWL=0.291, 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 YW8J7qfmAEDy for ; Fri, 7 Aug 2009 11:28:29 -0700 (PDT) Received: from mk-outboundfilter-6.mail.uk.tiscali.com (mk-outboundfilter-6.mail.uk.tiscali.com [212.74.114.14]) by core3.amsl.com (Postfix) with ESMTP id 7A7D83A685F for ; Fri, 7 Aug 2009 11:28:29 -0700 (PDT) X-Trace: 129601495/mk-outboundfilter-6.mail.uk.tiscali.com/PIPEX/$PIPEX-ACCEPTED/pipex-customers/62.188.100.81/None/cfinss@dial.pipex.com X-SBRS: None X-RemoteIP: 62.188.100.81 X-IP-MAIL-FROM: cfinss@dial.pipex.com X-SMTP-AUTH: X-MUA: Microsoft Outlook Express 6.00.2800.1106Produced By Microsoft MimeOLE V6.00.2800.1106 X-IP-BHB: Once X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ap0EAJcOfEo+vGRR/2dsb2JhbACDMEGMd79iCYQNBQ X-IronPort-AV: E=Sophos;i="4.43,343,1246834800"; d="scan'208";a="129601495" X-IP-Direction: IN Received: from 1cust81.tnt1.lnd9.gbr.da.uu.net (HELO allison) ([62.188.100.81]) by smtp.pipex.tiscali.co.uk with SMTP; 07 Aug 2009 19:28:29 +0100 Message-ID: <000701ca1784$604a89a0$0601a8c0@allison> From: "tom.petch" To: "Ersue, Mehmet \(NSN - DE/Munich\)" , References: Date: Fri, 7 Aug 2009 19:23:45 +0200 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.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Subject: [Netconf] CODE BEGINS wasRe: WGLC: draft-ietf-netconf-with-defaults-02 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: "tom.petch" List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Aug 2009 18:28:31 -0000 Mehmet I am not sure that I agree with you suggestion to wrap the example XML in this I-D with CODE BEGINS and CODE ENDS. It is not clear to me that this achieves what is intended. Code has become a technical, legal term, defining those parts of an I-D that can be extracted and modified without further permission outside the IETF standards process, as opposed to requiring special permission from the IETF Trust so to do. As RFC5377 s4.3 says, "Additionally, the Trustees of the IETF Trust should define a textual representation to be included in an IETF Contribution to indicate that a portion of the document is considered by the authors (and later, the working group, and upon approval, the IETF) to be code and thus subject to the permissions granted to use code." So I see this is nothing to do with an agreement in the IESG; it is a matter for Balazs and Andy, and perhaps the rest of the Working Group, whether or not they wish to make such a grant. While I see it as appropriate to grant such permission for Appendix A and Section 4, indeed it would by default be so, for myself, I would not grant it for informal snippets that may or may not have been validated and tested. So for me, wrapping up everything that is code-like so as to grant that extra copyright would be wrong. But as I say, it is in the first place up to Balazs and Andy. Tom Petch ----- Original Message ----- From: "Ersue, Mehmet (NSN - DE/Munich)" To: Sent: Thursday, August 06, 2009 5:55 PM Subject: Re: [Netconf] WGLC: draft-ietf-netconf-with-defaults-02 Hi, I reviewed the I-D draft-ietf-netconf-with-defaults-03.txt for WGLC. Please find my comments below. Abstract - s/manger/manager/ Ch. 1. Introduction - Last paragraph: I agree their is no explicite statement on default/non-default handling in RFC 4741. OTOH RFC 4741 says that in case a filter element is not defined the "entire configuration" is returned for a operation. As a native reader of the standard I interprete this as the default behaviour of NETCONF protocol, where both, default and non-default data, are returned. But the With-default draft assumes the opposite, i.e. the default behaviour of the NETCONF protocol is to suppress the default data in message. I think we need to align the two documents by choosing one of the options: a) add a clear statement to 4741bis saying that "the agent MAY suppress the default data" or b) address the assumption of a native 4741 reader in With-defaults draft I mentioned above. Ch. 1.1.2. NETCONF Terms I agree that if the default is '3' and the value is '3', it is considered to contain the default, regardless of how it was created. The draft does not specify explicitly set (default) data clearly. How do we handle non-default values which have been set explicitely, where the default is '3' but the value is _not_ '3' ? Are they suppressed too? Ch. 1.2. Current handling of default data - Change: o explicit: Report values if they are explicitly set. For state data this has the same effect as report-all to o explicit: Report values if they are explicitly set and match the default. For state data this has the same effect as report-all - s/report-all/report-all./ Ch. 2.5. Modifications to Existing Operations - Enclose the example code in and as a preparation for the code licence statement. Ch. 4. Data Model XSD - I checked the XSD model for it's validity. The XSD model is valid. - Unfortunately we have still the policy in O&M area to use XSD as the normative language for data models. If we want to publish the With-defaults draft soon I would suggest to follow the example of Partial Lock draft and indicate the XSD as normative. To keep them together I would put the XSD schema and YANG module into the appendix. OTOH if the authors and the WG decide that the With-default draft should be published together with 4747bis and after the publication of YANG we can mark the YAM as normative. In this case there is no need for XSD at all. Change log - 01-02: says "Placeholder for YAM added, XSD will be removed when 4741 provides the NETCONF YAM." We cannot remove the XSD if this draft gets published before YANG becomes normative. Cheers, Mehmet From: netconf-bounces@ietf.org [mailto:netconf-bounces@ietf.org] On Behalf Of ext Ersue, Mehmet (NSN - DE/Munich) Sent: Monday, August 03, 2009 11:42 PM To: netconf@ietf.org Subject: [Netconf] WGLC: draft-ietf-netconf-with-defaults-02 Dear NETCONF WG, we had a good progress on the draft "With-defaults capability for NETCONF". In the NETCONF session at IETF we decided to bring the draft to WGLC to initiate additional discussion. With this mail we start a WGLC for the "With-defaults capability for NETCONF" draft, which is planned to publish as a Proposed Standard RFC. The WGLC will run until August 21, 2009. Everybody on the NETCONF WG maillist PLEASE REVIEW the draft and send your comments to the NETCONF maillist. (http://tools.ietf.org/html/draft-ietf-netconf-with-defaults-02) Thank you and looking forward for your comments. Cheers, Mehmet -------------------------------------------------------------------------------- > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf > From j.schoenwaelder@jacobs-university.de Fri Aug 7 11:40: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 6EE833A6903 for ; Fri, 7 Aug 2009 11:40:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.207 X-Spam-Level: X-Spam-Status: No, score=-2.207 tagged_above=-999 required=5 tests=[AWL=0.042, 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 PfdFxm6tQu3u for ; Fri, 7 Aug 2009 11:40:18 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 225903A6452 for ; Fri, 7 Aug 2009 11:40:18 -0700 (PDT) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id C4855C0009; Fri, 7 Aug 2009 20:40:20 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius1.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id Zgl6Po4xmust; Fri, 7 Aug 2009 20:40:19 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 8EA97C0007; Fri, 7 Aug 2009 20:40:19 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 85F67B7EC13; Fri, 7 Aug 2009 20:40:18 +0200 (CEST) Date: Fri, 7 Aug 2009 20:40:18 +0200 From: Juergen Schoenwaelder To: Andy Bierman Message-ID: <20090807184018.GB2946@elstar.local> Mail-Followup-To: Andy Bierman , Randy Presuhn , NETCONF References: <4A7AFA9B.8030504@netconfcentral.com> <002701ca16bb$90da4700$6801a8c0@oemcomputer> <4A7C4604.5050008@netconfcentral.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4A7C4604.5050008@netconfcentral.com> User-Agent: Mutt/1.5.19 (2009-01-05) Cc: NETCONF Subject: Re: [Netconf] too many optional components? 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, 07 Aug 2009 18:40:19 -0000 On Fri, Aug 07, 2009 at 05:19:32PM +0200, Andy Bierman wrote: > Randy Presuhn wrote: > > Hi Andy - > > > > I think you're absolutely right on this. And it's not just the > > capabilities, but also the way module versioning and reuse > > will work that have this property. I'm soooo glad I don't > > have to implement this. :-) > > > > Hi Randy, > > Sorry for posting your private reply to the WG, > but you have a lot of NM and standards experience > across several SDOs and decades, so I think your perspective > and insights on interoperability need to be > considered by the WG. The intent is that > many people will attempt implementations. Well, to be fair, SNMP allows lots of variability in implementation as well and SNMP did not provide proper ways to announce things - so manager implementations either had to do quite some extensive probing to figure out what an agent supports or they settled on expecting the lowest common denominator. Given my SNMP experience, I believe NETCONF is on a good track since it provides means to announce the properties of a given server implementation and I assume this really makes things simpler. I believe we need to acknowledge implementation differences instead of claiming implementations are all the same even though in reality they are not. /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 Fri Aug 7 11:56: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 5DFCB3A690F for ; Fri, 7 Aug 2009 11:56:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.489 X-Spam-Level: X-Spam-Status: No, score=-2.489 tagged_above=-999 required=5 tests=[AWL=0.110, 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 KoJxSvWpXGke for ; Fri, 7 Aug 2009 11:56:35 -0700 (PDT) Received: from smtp108.sbc.mail.mud.yahoo.com (smtp108.sbc.mail.mud.yahoo.com [68.142.198.207]) by core3.amsl.com (Postfix) with SMTP id 72ED63A67F4 for ; Fri, 7 Aug 2009 11:56:35 -0700 (PDT) Received: (qmail 59724 invoked from network); 7 Aug 2009 18:56:37 -0000 Received: from unknown (HELO ?192.168.0.10?) (andy@67.125.157.61 with plain) by smtp108.sbc.mail.mud.yahoo.com with SMTP; 7 Aug 2009 18:56:36 -0000 X-YMail-OSG: EMYoEgkVM1mG31P.mJJFKiLElwmmcmuNuJ8s_Yxeh4N3QFz3Bp62Z3EJABdf27_PV.HLRwuulYJuvMOuagl4lFY6JVYH82xbqld.4b715D41goicm6gcvN00jFLEFnojLxZG4Vy9KiRKvJAYYkVlV0cikD6tMQ_CCEt8.TyULwAfRiIUAhg2ZEdRo3SG_7rtE4GVfXRkJVw5gsCnjc_OXm8c0BPxLDW4Uee.F_Sn4kFdhh_O7tObdBgItdEqiRDKlvSoNw2POVP5TX4- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4A7C791F.6080400@netconfcentral.com> Date: Fri, 07 Aug 2009 11:57:35 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.22 (X11/20090608) MIME-Version: 1.0 To: Andy Bierman , Randy Presuhn , NETCONF References: <4A7AFA9B.8030504@netconfcentral.com> <002701ca16bb$90da4700$6801a8c0@oemcomputer> <4A7C4604.5050008@netconfcentral.com> <20090807184018.GB2946@elstar.local> In-Reply-To: <20090807184018.GB2946@elstar.local> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [Netconf] too many optional components? 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, 07 Aug 2009 18:56:36 -0000 Juergen Schoenwaelder wrote: > On Fri, Aug 07, 2009 at 05:19:32PM +0200, Andy Bierman wrote: >> Randy Presuhn wrote: >>> Hi Andy - >>> >>> I think you're absolutely right on this. And it's not just the >>> capabilities, but also the way module versioning and reuse >>> will work that have this property. I'm soooo glad I don't >>> have to implement this. :-) >>> >> Hi Randy, >> >> Sorry for posting your private reply to the WG, >> but you have a lot of NM and standards experience >> across several SDOs and decades, so I think your perspective >> and insights on interoperability need to be >> considered by the WG. The intent is that >> many people will attempt implementations. > > Well, to be fair, SNMP allows lots of variability in implementation as > well and SNMP did not provide proper ways to announce things - so > manager implementations either had to do quite some extensive probing > to figure out what an agent supports or they settled on expecting the > lowest common denominator. Given my SNMP experience, I believe NETCONF > is on a good track since it provides means to announce the properties > of a given server implementation and I assume this really makes things > simpler. I believe we need to acknowledge implementation differences > instead of claiming implementations are all the same even though in > reality they are not. > It is simply a design choice whether to make the conformance for every little bit of new functionality to be optional, or whether to bundle them together into a much larger conformance package, sometimes called a "protocol version". Simply announcing that you support combination #42 out of 1000 does not help NMS code developers who have to keep rewriting code because another new capability changes the way 2 other capabilities work. This is not the same thing as an unknown mix of MIB modules that may be present on each agent. Some capabilities (like rollback-on-error) add 1 enum to 1 parameter to 1 RPC operation. IMO, this micro-partitioning of functionality is a way to avoid real standards and real interoperability, not improve it. > /js > Andy From j.schoenwaelder@jacobs-university.de Fri Aug 7 12:13: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 879F93A6D7B for ; Fri, 7 Aug 2009 12:13:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.207 X-Spam-Level: X-Spam-Status: No, score=-2.207 tagged_above=-999 required=5 tests=[AWL=0.042, 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 CYZxdwdcy4Qy for ; Fri, 7 Aug 2009 12:13:32 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 728063A6CBC for ; Fri, 7 Aug 2009 12:13:32 -0700 (PDT) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 75D2DC0009; Fri, 7 Aug 2009 21:13:35 +0200 (CEST) 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 4n4OxnpJWXi6; Fri, 7 Aug 2009 21:13:34 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 203A6C0007; Fri, 7 Aug 2009 21:13:34 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 23DF7B7ECFA; Fri, 7 Aug 2009 21:13:33 +0200 (CEST) Date: Fri, 7 Aug 2009 21:13:33 +0200 From: Juergen Schoenwaelder To: Andy Bierman Message-ID: <20090807191333.GA2996@elstar.local> Mail-Followup-To: Andy Bierman , Randy Presuhn , NETCONF References: <4A7AFA9B.8030504@netconfcentral.com> <002701ca16bb$90da4700$6801a8c0@oemcomputer> <4A7C4604.5050008@netconfcentral.com> <20090807184018.GB2946@elstar.local> <4A7C791F.6080400@netconfcentral.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4A7C791F.6080400@netconfcentral.com> User-Agent: Mutt/1.5.19 (2009-01-05) Cc: NETCONF Subject: Re: [Netconf] too many optional components? 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, 07 Aug 2009 19:13:33 -0000 On Fri, Aug 07, 2009 at 08:57:35PM +0200, Andy Bierman wrote: > It is simply a design choice whether to make the conformance > for every little bit of new functionality to be optional, or whether > to bundle them together into a much larger conformance package, > sometimes called a "protocol version". > > Simply announcing that you support combination #42 out of 1000 > does not help NMS code developers who have to keep rewriting code > because another new capability changes the way 2 other capabilities work. I also does not make sense to have one protocol versions while in reality implementations can implement that one version in several different ways. I am with you in the cases where capabilities change semantics of operations - this is simply bad design. > This is not the same thing as an unknown mix of MIB modules that may > be present on each agent. Some capabilities (like > rollback-on-error) add 1 enum to 1 parameter to 1 RPC operation. > IMO, this micro-partitioning of functionality is a way to avoid real > standards and real interoperability, not improve it. Oh, I am talking about MIB modules. Just think of pretty fundamental things like SNMP's RowStatus - do not expect all agents to handle things in the same way; some only support createAndGo, others only dribble mode; some even only single varbind sets while yet others prefer to get one row in a single set - but they might freak out if you try multiple rows in a single set. I believe differences like these do not go away by pretending they do not exist. And whether we will achieve interoperability will be seen by doing the experiment of getting this out of the door and good interoperability tests in place. Real interoperability comes from implementation interoperability testing and open reference implementations. Good open specifications help with that but only up to a certain point. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From randy_presuhn@mindspring.com Fri Aug 7 12:55:34 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 BD79E3A68E9 for ; Fri, 7 Aug 2009 12:55:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.11 X-Spam-Level: X-Spam-Status: No, score=-1.11 tagged_above=-999 required=5 tests=[BAYES_05=-1.11] 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 h86bIbhasHJT for ; Fri, 7 Aug 2009 12:55:34 -0700 (PDT) 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 EC07B3A68A5 for ; Fri, 7 Aug 2009 12:55:33 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=BKTNo/dL8eutEkTmQftPWEn2qv2G/jibxv5jV1l2MleP0rBYT2zjRt55lqfk8KGB; 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.33.94.198] (helo=oemcomputer) by elasmtp-mealy.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1MZVXI-0000Tv-Ek for netconf@ietf.org; Fri, 07 Aug 2009 15:55:32 -0400 Message-ID: <001801ca1799$5833b7e0$6801a8c0@oemcomputer> From: "Randy Presuhn" To: "NETCONF" References: <4A7AFA9B.8030504@netconfcentral.com> <002701ca16bb$90da4700$6801a8c0@oemcomputer> <4A7C4604.5050008@netconfcentral.com> <20090807184018.GB2946@elstar.local> <4A7C791F.6080400@netconfcentral.com> <20090807191333.GA2996@elstar.local> Date: Fri, 7 Aug 2009 12:57:49 -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: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d88884f945684cbf696884dcb68145259a54028abba77d8c1d9a350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 99.33.94.198 Subject: Re: [Netconf] too many optional components? 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, 07 Aug 2009 19:55:34 -0000 Hi - > From: "Juergen Schoenwaelder" > To: "Andy Bierman" > Cc: "Randy Presuhn" ; "NETCONF" > Sent: Friday, August 07, 2009 12:13 PM > Subject: Re: [Netconf] too many optional components? ... > Oh, I am talking about MIB modules. Just think of pretty fundamental > things like SNMP's RowStatus - do not expect all agents to handle > things in the same way; some only support createAndGo, others only > dribble mode; some even only single varbind sets while yet others > prefer to get one row in a single set - but they might freak out if > you try multiple rows in a single set. I believe differences like > these do not go away by pretending they do not exist. ... For an implementation to "freak out if you try multiple rows in a single set" is a bug, plain and simple. The variations that in my experience were most difficult to cope with in manager code were not differences in behaviour permitted by the protocol or MIB designs, but rather the astonishing array of misbehaviour in violation of the protocol or MIB specifications. RowStatus is horrifically complicated, largely due to SNMP and the SMI's lack of a real object model and ad hoc approach to life-cycle. (But wait, Netconf doesn't have one either.) Still, we should not confuse implementation errors with variability permitted by the specifications. Randy From phil@juniper.net Fri Aug 7 14:48: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 163293A6E24 for ; Fri, 7 Aug 2009 14:48:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.541 X-Spam-Level: X-Spam-Status: No, score=-6.541 tagged_above=-999 required=5 tests=[AWL=0.058, 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 LgNMblwyBtCf for ; Fri, 7 Aug 2009 14:48:17 -0700 (PDT) Received: from exprod7og111.obsmtp.com (exprod7og111.obsmtp.com [64.18.2.175]) by core3.amsl.com (Postfix) with ESMTP id 66BCD3A6F34 for ; Fri, 7 Aug 2009 14:48:14 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob111.postini.com ([64.18.6.12]) with SMTP ID DSNKSnyhH5HBfHCJsxYbRpEwxzLyhgxMCYA5@postini.com; Fri, 07 Aug 2009 14:48:20 PDT 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; Fri, 7 Aug 2009 14:45:15 -0700 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, 7 Aug 2009 14:45:16 -0700 Received: from emailsmtp56.jnpr.net ([172.24.60.77]) by p-emlb02-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Fri, 7 Aug 2009 14:45:15 -0700 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp56.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Fri, 7 Aug 2009 14:45:14 -0700 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 n77LjDd13391; Fri, 7 Aug 2009 14:45:13 -0700 (PDT) (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 n77LXY4t033853; Fri, 7 Aug 2009 21:33:35 GMT (envelope-from phil@idle.juniper.net) Message-ID: <200908072133.n77LXY4t033853@idle.juniper.net> To: "tom.petch" In-Reply-To: <000701ca1784$604a89a0$0601a8c0@allison> Date: Fri, 7 Aug 2009 17:33:34 -0400 From: Phil Shafer X-OriginalArrivalTime: 07 Aug 2009 21:45:14.0534 (UTC) FILETIME=[58CE4C60:01CA17A8] MIME-Version: 1.0 Content-Type: text/plain Cc: netconf@ietf.org Subject: Re: [Netconf] CODE BEGINS wasRe: WGLC: draft-ietf-netconf-with-defaults-02 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, 07 Aug 2009 21:48:18 -0000 "tom.petch" writes: >I am not sure that I agree with you suggestion to wrap the example XML in this >I-D with CODE BEGINS and CODE ENDS. It is not clear to me that this achieves >what is intended. --BLOCK-BEGINS-- or --DATA-BEGINS--? XML or YANG isn't really code anyway. Thanks, Phil From andy@netconfcentral.com Fri Aug 7 16:10: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 E386C3A6875 for ; Fri, 7 Aug 2009 16:10:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.491 X-Spam-Level: X-Spam-Status: No, score=-2.491 tagged_above=-999 required=5 tests=[AWL=0.108, 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 1zlQF46jUCu8 for ; Fri, 7 Aug 2009 16:10:21 -0700 (PDT) Received: from smtp110.sbc.mail.mud.yahoo.com (smtp110.sbc.mail.mud.yahoo.com [68.142.198.209]) by core3.amsl.com (Postfix) with SMTP id 571D028C224 for ; Fri, 7 Aug 2009 16:10:18 -0700 (PDT) Received: (qmail 48374 invoked from network); 7 Aug 2009 23:10:19 -0000 Received: from unknown (HELO ?192.168.0.10?) (andy@67.125.157.61 with plain) by smtp110.sbc.mail.mud.yahoo.com with SMTP; 7 Aug 2009 23:10:18 -0000 X-YMail-OSG: yn88k9oVM1msLZUBOJwIKiSWUEDccrSxifP9apcQ5xLVMD5_DKSwhhG57UD0pn1IaDKPO7kFbCAv88K7kpgJ0ARlfTG5BEsbtd5LxMK4HenN6qt.rno28zUAdsuST39brSFBLKKD6_nhoQNTqNfvJ.bzpo4GImwPE.GNXl2SuIRIz1VAY8zW9EQMLCNwq29f6ItNjIzMw0.YdlUDjcJNX9UAJ0W9O3Qvlqo_.nKX0FGtJlGhqMqeZ3.RgNm051tS42xC2igHuXd4CIGzf4lLxbny90mz.B.aV8byp8wBXE1umTE1Wbc- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4A7CB496.7000205@netconfcentral.com> Date: Fri, 07 Aug 2009 16:11:18 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.22 (X11/20090608) MIME-Version: 1.0 To: Andy Bierman , Randy Presuhn , NETCONF References: <4A7AFA9B.8030504@netconfcentral.com> <002701ca16bb$90da4700$6801a8c0@oemcomputer> <4A7C4604.5050008@netconfcentral.com> <20090807184018.GB2946@elstar.local> <4A7C791F.6080400@netconfcentral.com> <20090807191333.GA2996@elstar.local> In-Reply-To: <20090807191333.GA2996@elstar.local> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [Netconf] too many optional components? 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, 07 Aug 2009 23:10:22 -0000 Juergen Schoenwaelder wrote: > On Fri, Aug 07, 2009 at 08:57:35PM +0200, Andy Bierman wrote: > >> It is simply a design choice whether to make the conformance >> for every little bit of new functionality to be optional, or whether >> to bundle them together into a much larger conformance package, >> sometimes called a "protocol version". >> >> Simply announcing that you support combination #42 out of 1000 >> does not help NMS code developers who have to keep rewriting code >> because another new capability changes the way 2 other capabilities work. > > I also does not make sense to have one protocol versions while in > reality implementations can implement that one version in several > different ways. I am with you in the cases where capabilities change > semantics of operations - this is simply bad design. > There has always been a tug-of-war between NMS and agent developers over this issue. The NMS developers call it 'variability' and it's a bad thing, and the agent developers call it 'flexibility', and it's a good thing. Sometimes, real standards requires real work to get the right running code. In the old days, before if-feature and capabilities, working groups had to make tough decisions about what to put in the protocol (or MIB module). If 1 or 2 vendors could not convince everybody else they needed to implement this new thing, then it got left out of the standard. That is not true anymore. >> This is not the same thing as an unknown mix of MIB modules that may >> be present on each agent. Some capabilities (like >> rollback-on-error) add 1 enum to 1 parameter to 1 RPC operation. >> IMO, this micro-partitioning of functionality is a way to avoid real >> standards and real interoperability, not improve it. > > Oh, I am talking about MIB modules. Just think of pretty fundamental > things like SNMP's RowStatus - do not expect all agents to handle > things in the same way; some only support createAndGo, others only > dribble mode; some even only single varbind sets while yet others > prefer to get one row in a single set - but they might freak out if > you try multiple rows in a single set. I believe differences like > these do not go away by pretending they do not exist. > OK, the first indicator that we had a that problem is that it takes 12 pages to define the RowStatus TC. But we ignored that sign. RowStatus is so complicated that even standard MIBs started defining hacks in DESCRIPTION clauses to leave out the parts that were too hard. > And whether we will achieve interoperability will be seen by doing the > experiment of getting this out of the door and good interoperability > tests in place. Real interoperability comes from implementation > interoperability testing and open reference implementations. Good open > specifications help with that but only up to a certain point. > is this where we say amen! ? running code makes better specifications makes better running code makes... > /js > Andy From andy@netconfcentral.com Fri Aug 7 21:36: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 9B0A53A69AF for ; Fri, 7 Aug 2009 21:36:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.489 X-Spam-Level: X-Spam-Status: No, score=-2.489 tagged_above=-999 required=5 tests=[AWL=0.110, 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 vh0bX-oh61Ht for ; Fri, 7 Aug 2009 21:36:54 -0700 (PDT) Received: from smtp109.sbc.mail.mud.yahoo.com (smtp109.sbc.mail.mud.yahoo.com [68.142.198.208]) by core3.amsl.com (Postfix) with SMTP id C538C3A6A0C for ; Fri, 7 Aug 2009 21:36:54 -0700 (PDT) Received: (qmail 11656 invoked from network); 8 Aug 2009 04:36:56 -0000 Received: from unknown (HELO ?192.168.0.10?) (andy@67.125.157.61 with plain) by smtp109.sbc.mail.mud.yahoo.com with SMTP; 8 Aug 2009 04:36:56 -0000 X-YMail-OSG: qRdp3zIVM1lyGqLWwL9zqNcIHE4rHNQWC6bDCe876rG0gwKBJz3M1YYldM2nxLYdbUSDxf8hH1sx4fgCftmLGE9uW5qDpjNHjn7pmg9h4WzRsfDOBEZBX36lPLCZa.iQzHZygHQN21FaycCZEtrntjqGMgAQSwBMvpcwaTaLgKh1uBCEqQ7VFQZtG7hD71lW0o.OeYpeB0HxIEmugPpPKCaaqXGDuCTUEOt1beDZfp8cZbU4gfbefB_mzwnrSAYnQE.dGCPvQkg.yUcTPal5kZZoxU110wfSHIPRv2W33l04Cx0- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4A7D0125.2040700@netconfcentral.com> Date: Fri, 07 Aug 2009 21:37:57 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.22 (X11/20090608) MIME-Version: 1.0 To: Randy Presuhn References: <4A7AFA9B.8030504@netconfcentral.com> <002701ca16bb$90da4700$6801a8c0@oemcomputer> <4A7C4604.5050008@netconfcentral.com> <20090807184018.GB2946@elstar.local> <4A7C791F.6080400@netconfcentral.com> <20090807191333.GA2996@elstar.local> <001801ca1799$5833b7e0$6801a8c0@oemcomputer> In-Reply-To: <001801ca1799$5833b7e0$6801a8c0@oemcomputer> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: NETCONF Subject: Re: [Netconf] too many optional components? 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, 08 Aug 2009 04:36:55 -0000 Randy Presuhn wrote: > Hi - > >> From: "Juergen Schoenwaelder" >> To: "Andy Bierman" >> Cc: "Randy Presuhn" ; "NETCONF" >> Sent: Friday, August 07, 2009 12:13 PM >> Subject: Re: [Netconf] too many optional components? > ... >> Oh, I am talking about MIB modules. Just think of pretty fundamental >> things like SNMP's RowStatus - do not expect all agents to handle >> things in the same way; some only support createAndGo, others only >> dribble mode; some even only single varbind sets while yet others >> prefer to get one row in a single set - but they might freak out if >> you try multiple rows in a single set. I believe differences like >> these do not go away by pretending they do not exist. > ... > > For an implementation to "freak out if you try multiple rows in a single set" > is a bug, plain and simple. The variations that in my experience were > most difficult to cope with in manager code were not differences in behaviour > permitted by the protocol or MIB designs, but rather the astonishing array > of misbehaviour in violation of the protocol or MIB specifications. > > RowStatus is horrifically complicated, largely due to SNMP and the SMI's > lack of a real object model and ad hoc approach to life-cycle. (But wait, > Netconf doesn't have one either.) Still, we should not confuse implementation > errors with variability permitted by the specifications. > Since you brought up RowStatus... Is the NETCONF WG going to ignore 'not-in-service' forever? This could be considered the same as the 'pre-provisioning' feature that NETCDNF does not support. Does it matter that active config looks exactly the same as pending config (e.g., waiting for specific hardware to be installed)? > Randy Andy From j.schoenwaelder@jacobs-university.de Fri Aug 7 23:25: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 6D0AF3A6979 for ; Fri, 7 Aug 2009 23:25:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.208 X-Spam-Level: X-Spam-Status: No, score=-2.208 tagged_above=-999 required=5 tests=[AWL=0.041, 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 gVK2Ov6ToYqq for ; Fri, 7 Aug 2009 23:25:14 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 66BF23A698C for ; Fri, 7 Aug 2009 23:25:14 -0700 (PDT) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id D3439C000B; Sat, 8 Aug 2009 08:25:16 +0200 (CEST) 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 kf76CJZ5arFO; Sat, 8 Aug 2009 08:25:15 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 9482CC0005; Sat, 8 Aug 2009 08:25:15 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 912D5B7F135; Sat, 8 Aug 2009 08:25:14 +0200 (CEST) Date: Sat, 8 Aug 2009 08:25:14 +0200 From: Juergen Schoenwaelder To: Phil Shafer Message-ID: <20090808062514.GB3279@elstar.local> Mail-Followup-To: Phil Shafer , "tom.petch" , "netconf@ietf.org" References: <000701ca1784$604a89a0$0601a8c0@allison> <200908072133.n77LXY4t033853@idle.juniper.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200908072133.n77LXY4t033853@idle.juniper.net> User-Agent: Mutt/1.5.19 (2009-01-05) Cc: "netconf@ietf.org" Subject: Re: [Netconf] CODE BEGINS wasRe: WGLC: draft-ietf-netconf-with-defaults-02 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: Sat, 08 Aug 2009 06:25:15 -0000 On Fri, Aug 07, 2009 at 11:33:34PM +0200, Phil Shafer wrote: > "tom.petch" writes: > >I am not sure that I agree with you suggestion to wrap the example XML in this > >I-D with CODE BEGINS and CODE ENDS. It is not clear to me that this achieves > >what is intended. > > --BLOCK-BEGINS-- or --DATA-BEGINS--? XML or YANG isn't really code > anyway. I think there are two issues to consider here. The first one is to add marks so that a generic rfcstrip tool can extract stuff out of IDs/RFCs - a yangstrip is much harder to do compared to an smistrip. For that, I once proposed to mark things like this: == start "foo.yang" module foo { // ... } == end "foo.yang" This would be a simple convention to make it easy to extract stuff out of IDs. The second thing are copyright considerations and while I am not a big fan of this kind of affairs, I guess YANG modules need to carry the appropriate boilerplate text, as we do with MIB modules. As a matter of fact, YANG modules will be extracted from RFCs and they will be shipped as part of larger software systems so it is important to have the legal words in these extracted fragments that make it clear that doing so it allowed. That said, I do not think we need to mark every little example as code / extractable fragments. /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 Sat Aug 8 07:26: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 312643A6B5D for ; Sat, 8 Aug 2009 07:26:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.543 X-Spam-Level: X-Spam-Status: No, score=-6.543 tagged_above=-999 required=5 tests=[AWL=0.056, 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 usYrAycI6wm0 for ; Sat, 8 Aug 2009 07:26:30 -0700 (PDT) Received: from exprod7og111.obsmtp.com (exprod7og111.obsmtp.com [64.18.2.175]) by core3.amsl.com (Postfix) with ESMTP id 8A6073A69BC for ; Sat, 8 Aug 2009 07:26:29 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob111.postini.com ([64.18.6.12]) with SMTP ID DSNKSn2LEQQQmbKtnUxpOx0YLCQ1qgYL0Hjr@postini.com; Sat, 08 Aug 2009 07:26:34 PDT 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; Sat, 8 Aug 2009 07:23:51 -0700 Received: from p-emlb01-sac.jnpr.net ([66.129.254.46]) by p-emfe01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Sat, 8 Aug 2009 07:23:51 -0700 Received: from emailsmtp56.jnpr.net ([172.24.60.77]) by p-emlb01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Sat, 8 Aug 2009 07:23:51 -0700 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp56.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Sat, 8 Aug 2009 07:23:50 -0700 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 n78ENnd73523; Sat, 8 Aug 2009 07:23:49 -0700 (PDT) (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 n78ECA0h046498; Sat, 8 Aug 2009 14:12:10 GMT (envelope-from phil@idle.juniper.net) Message-ID: <200908081412.n78ECA0h046498@idle.juniper.net> To: Andy Bierman In-Reply-To: <4A7D0125.2040700@netconfcentral.com> Date: Sat, 8 Aug 2009 10:12:09 -0400 From: Phil Shafer X-OriginalArrivalTime: 08 Aug 2009 14:23:50.0454 (UTC) FILETIME=[D97A2560:01CA1833] MIME-Version: 1.0 Content-Type: text/plain Cc: NETCONF Subject: Re: [Netconf] too many optional components? 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, 08 Aug 2009 14:26:31 -0000 Andy Bierman writes: >Is the NETCONF WG going to ignore 'not-in-service' forever? >This could be considered the same as the 'pre-provisioning' >feature that NETCDNF does not support. Does it matter that >active config looks exactly the same as pending config >(e.g., waiting for specific hardware to be installed)? FWIW, I follow an "ephemeral" model, where the configuration is valid based only on the configuration, not the current state of the world. This means that the installed hardware is not considered when judging validity. Pre-provisioning means only that you create the config for missing hardware, and when the hardware is hotplugged in, the device sees it and applies the proper config. Not doing this model means that someone can remove a FRU and suddenly your config will not commit (and in ways the committer may not be able to repair). So 'pre-provisioning' is already handled, in this respect. Thanks, Phil From andy@netconfcentral.com Sat Aug 8 07:34: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 AA1E53A6BD3 for ; Sat, 8 Aug 2009 07:34:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.491 X-Spam-Level: X-Spam-Status: No, score=-2.491 tagged_above=-999 required=5 tests=[AWL=0.108, 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 0WpiiB8ZnycS for ; Sat, 8 Aug 2009 07:34:38 -0700 (PDT) Received: from n12a.bullet.mail.mud.yahoo.com (n12a.bullet.mail.mud.yahoo.com [209.191.125.177]) by core3.amsl.com (Postfix) with SMTP id F31153A6BD7 for ; Sat, 8 Aug 2009 07:33:47 -0700 (PDT) Received: from [68.142.200.225] by n12.bullet.mail.mud.yahoo.com with NNFMP; 08 Aug 2009 14:33:49 -0000 Received: from [68.142.201.71] by t6.bullet.mud.yahoo.com with NNFMP; 08 Aug 2009 14:33:49 -0000 Received: from [127.0.0.1] by omp423.mail.mud.yahoo.com with NNFMP; 08 Aug 2009 14:33:49 -0000 X-Yahoo-Newman-Id: 852960.50934.bm@omp423.mail.mud.yahoo.com Received: (qmail 41207 invoked from network); 8 Aug 2009 14:33:49 -0000 Received: from unknown (HELO ?192.168.0.10?) (andy@67.125.157.61 with plain) by smtp106.sbc.mail.sp1.yahoo.com with SMTP; 8 Aug 2009 14:33:49 -0000 X-YMail-OSG: Wr6Tp_sVM1l7E2D.oc2gR7Nq_bM8NUUUwRpwb04.V76fsM48XyVgP2RWWCcFs6GACRD5I51P5T5caAPhVKbb9GyGc7yxw9a4zliBCJiDPXwC9vcYmMjt0xiHBdCwpXz4ZR_HXdrcw34stsLQW2OP4w0Kz5wMspgx9uEtSxpQsO6uUTk__J66cwW3rpBtoOwmTm35v3mvxsBearXT2UWwhag9uk_q0Mv34udHt_bElc3uBzYkG36m19opvvsL.qMJxehQGDRevqbmIXoyqMto6arRnjhugGdzM71lhcT.aGPHGn5CbDA- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4A7D8D0D.7050805@netconfcentral.com> Date: Sat, 08 Aug 2009 07:34:53 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.22 (X11/20090608) MIME-Version: 1.0 To: Phil Shafer , "tom.petch" , "netconf@ietf.org" References: <000701ca1784$604a89a0$0601a8c0@allison> <200908072133.n77LXY4t033853@idle.juniper.net> <20090808062514.GB3279@elstar.local> In-Reply-To: <20090808062514.GB3279@elstar.local> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [Netconf] CODE BEGINS wasRe: WGLC: draft-ietf-netconf-with-defaults-02 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, 08 Aug 2009 14:34:39 -0000 Juergen Schoenwaelder wrote: > On Fri, Aug 07, 2009 at 11:33:34PM +0200, Phil Shafer wrote: >> "tom.petch" writes: >>> I am not sure that I agree with you suggestion to wrap the example XML in this >>> I-D with CODE BEGINS and CODE ENDS. It is not clear to me that this achieves >>> what is intended. >> --BLOCK-BEGINS-- or --DATA-BEGINS--? XML or YANG isn't really code >> anyway. > > I think there are two issues to consider here. The first one is to > add marks so that a generic rfcstrip tool can extract stuff out of > IDs/RFCs - a yangstrip is much harder to do compared to an smistrip. > For that, I once proposed to mark things like this: > > == start "foo.yang" > > module foo { > // ... > } > > == end "foo.yang" > I like this idea. > This would be a simple convention to make it easy to extract stuff out > of IDs. The second thing are copyright considerations and while I am > not a big fan of this kind of affairs, I guess YANG modules need to > carry the appropriate boilerplate text, as we do with MIB modules. As > a matter of fact, YANG modules will be extracted from RFCs and they > will be shipped as part of larger software systems so it is important > to have the legal words in these extracted fragments that make it > clear that doing so it allowed. > the YANG usage guidelines draft needs to deal with this, so the rule needs to be clear: YANG CODE == a complete [sub]module that NETCONF devices are supposed to implement YANG example == YANG snippets that are meant to help understand the document content > That said, I do not think we need to mark every little example as > code / extractable fragments. > agreed > /js > Andy From phil@juniper.net Sat Aug 8 07:39:42 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 D5C523A6BAB for ; Sat, 8 Aug 2009 07:39:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.646 X-Spam-Level: X-Spam-Status: No, score=-5.646 tagged_above=-999 required=5 tests=[AWL=-0.847, BAYES_00=-2.599, J_CHICKENPOX_26=0.6, 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 OvQbfo0Hzbdj for ; Sat, 8 Aug 2009 07:39:42 -0700 (PDT) Received: from exprod7og105.obsmtp.com (exprod7og105.obsmtp.com [64.18.2.163]) by core3.amsl.com (Postfix) with ESMTP id EE6463A6C0C for ; Sat, 8 Aug 2009 07:39:40 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob105.postini.com ([64.18.6.12]) with SMTP ID DSNKSn2OLjTrkAlJ4Sg2XAXEKAcSnkBSjE+S@postini.com; Sat, 08 Aug 2009 07:39:44 PDT 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; Sat, 8 Aug 2009 07:38:23 -0700 Received: from p-emlb02-sac.jnpr.net ([66.129.254.47]) by p-emfe01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Sat, 8 Aug 2009 07:38:23 -0700 Received: from emailsmtp56.jnpr.net ([172.24.60.77]) by p-emlb02-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Sat, 8 Aug 2009 07:38:23 -0700 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp56.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Sat, 8 Aug 2009 07:38:22 -0700 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 n78EcMd77828; Sat, 8 Aug 2009 07:38:22 -0700 (PDT) (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 n78EQgOs046620; Sat, 8 Aug 2009 14:26:43 GMT (envelope-from phil@idle.juniper.net) Message-ID: <200908081426.n78EQgOs046620@idle.juniper.net> To: Martin Bjorklund In-Reply-To: <20090731.165452.179797677.mbj@tail-f.com> Date: Sat, 8 Aug 2009 10:26:42 -0400 From: Phil Shafer X-OriginalArrivalTime: 08 Aug 2009 14:38:22.0889 (UTC) FILETIME=[E17D2990:01CA1835] MIME-Version: 1.0 Content-Type: text/plain Cc: netconf@ietf.org Subject: Re: [Netconf] Comments on draft-ietf-netconf-monitoring-06.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: Sat, 08 Aug 2009 14:39:42 -0000 Martin Bjorklund writes: >> urn:ietf:params:xml:ns:netconf:monitor:1.0 >s/state/monitor is fine with me, but I don't agree we should add a >version number. We have the revision statement in YANG modules to >handle versioning. The YANG module is non-normative, so implementations won't announce the capability with YANG style (and panache), so you need another mechanism for versioning. Another reason to wait for YANG, IMHO. >> (a) should ietf models be under a top-level "/ietf/" container? >As Andy said this has been discussed and resolved before. Adding this >hierarchy would just add unnecessay containers. The namespace URI >provides the context for the top-level node. These "unnecessary containers" provide an organizational hierarchy. Without this, all modules will appear at the top level. This would be an unbearable bad decision. If there are 10 bgp yang modules, how do I say "give me all your bgp config" to a device? I can't just ask for the /ietf/protocols/routing/bgp hiearchy and get all 10 overlapping (augmented) module contents. >> (b) Why is there a "-state" suffix? Most of this isn't state data, >> per se (schemas are not state data). It seems like you need to >> separate this. But there is also some question about who we will >> organize data. There are many advocates of intermixing state data >> without the same tree as configuration data, so config=false nodes >> will intermix with config=true ones. I'm not convinced that this >> works well, but it's something we need to think about for this draft. > >The model in this draft does not mix config and state, so I am not >sure what we need to think about? This is an early data model, and will be used as a precedent. Adding the "-state" suffix means when someone adds config, you'll need a new hierarchy instead of augmenting the existing /ietf/management/netconf one. >> 2.1.3. The /netconf-state/schemas Subtree >> >> Why isn't "namespace" the key, instead of identifier? > >The current indexing allows you to list (and fetch) YANG submodules >(and equivalent for XSD and RNG). Shouldn't these be organized in a hierarchical manner, so submodules appear under modules? >In XSD, there is a 'version' attribute on the xs:schema element. >Some XML schemas use that, and some encode the version in the URI. Given that we hope/expect YANG to take over the world, using "version" when we clearly mean "revision" is an unnecessary translation that is annoying at best, confusing at worst. >Maybe it should say "network management subsystem" or something, like >sysUpTime. What's the value of this field? Why would anyone use it? What would they use it for? If you want to have it in the module, it needs a convincing use case, imho. Thanks, Phil From andy@netconfcentral.com Sat Aug 8 07:43:34 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 BEC333A6BDD for ; Sat, 8 Aug 2009 07:43:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.326 X-Spam-Level: X-Spam-Status: No, score=-2.326 tagged_above=-999 required=5 tests=[AWL=-0.061, 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 J0rkJtp9f6K6 for ; Sat, 8 Aug 2009 07:43:34 -0700 (PDT) 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 1B9213A6BB0 for ; Sat, 8 Aug 2009 07:43:34 -0700 (PDT) Received: (qmail 13380 invoked from network); 8 Aug 2009 14:43:35 -0000 Received: from unknown (HELO ?192.168.0.10?) (andy@67.125.157.61 with plain) by smtp125.sbc.mail.sp1.yahoo.com with SMTP; 8 Aug 2009 14:43:35 -0000 X-YMail-OSG: XRYHuWkVM1npZmuXVkvcjk6MEjtz2rNY7OoE6pAxCAtrw13Z_N5CApFPtSMh6sWcxnzzZHqR2V8DGDRfhkrvfCfjVjcEr.5wP4JSB540HwPgw30HuThvnZpJZBhI8OEn6U6PPwWUtA2eeU7TFUTEpMuF031bnciZGWtZOnFVn5ZT9yBptuaiWPvebusH5HllJU__09ZRCC0JwB9dJGtxFuwbRjZAU.dJ1dZhw8hd5La9U0dNkxnRKQlvGeE2oBL0HDM8pF4Lg4yvPn_RFL7MjpQD4MpUnjb15u.hKSlY6l6DfgYTMfY- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4A7D8EDB.1000908@netconfcentral.com> Date: Sat, 08 Aug 2009 07:42:35 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.22 (X11/20090608) MIME-Version: 1.0 To: Phil Shafer References: <200908081412.n78ECA0h046498@idle.juniper.net> In-Reply-To: <200908081412.n78ECA0h046498@idle.juniper.net> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: NETCONF Subject: Re: [Netconf] too many optional components? 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, 08 Aug 2009 14:43:34 -0000 Phil Shafer wrote: > Andy Bierman writes: >> Is the NETCONF WG going to ignore 'not-in-service' forever? >> This could be considered the same as the 'pre-provisioning' >> feature that NETCDNF does not support. Does it matter that >> active config looks exactly the same as pending config >> (e.g., waiting for specific hardware to be installed)? > > FWIW, I follow an "ephemeral" model, where the configuration is > valid based only on the configuration, not the current state of the > world. This means that the installed hardware is not considered > when judging validity. Pre-provisioning means only that you create > the config for missing hardware, and when the hardware is hotplugged > in, the device sees it and applies the proper config. Not doing > this model means that someone can remove a FRU and suddenly your > config will not commit (and in ways the committer may not be able > to repair). > > So 'pre-provisioning' is already handled, in this respect. > good -- I do the same thing. It does not matter if the the callback code 'arrives' before or after the config. Since callbacks are optional, there is currently no way for the stack to even know if any instrumentation is missing. This is an area where specialized RPCs would really help, such as get-status(). Something like the /etc/rc.d/init.d/serverd stuff in Fedora would really help in NETCONF. But now I'm talking about structured APIs for network services, which is so far off the charter radar, that I'll shut up now... > Thanks, > Phil > Andy From phil@juniper.net Sat Aug 8 07:44:34 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 4671D3A6A61 for ; Sat, 8 Aug 2009 07:44:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.522 X-Spam-Level: X-Spam-Status: No, score=-6.522 tagged_above=-999 required=5 tests=[AWL=0.077, 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 wYhprfAOVjir for ; Sat, 8 Aug 2009 07:44:33 -0700 (PDT) Received: from exprod7og102.obsmtp.com (exprod7og102.obsmtp.com [64.18.2.157]) by core3.amsl.com (Postfix) with ESMTP id 65B1A3A6D7C for ; Sat, 8 Aug 2009 07:44:02 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob102.postini.com ([64.18.6.12]) with SMTP ID DSNKSn2PM4ZEaP9VyGO7z37wxcdTQuUFhcWN@postini.com; Sat, 08 Aug 2009 07:44:06 PDT 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; Sat, 8 Aug 2009 07:40:59 -0700 Received: from p-emlb02-sac.jnpr.net ([66.129.254.47]) by p-emfe01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Sat, 8 Aug 2009 07:40:59 -0700 Received: from emailsmtp56.jnpr.net ([172.24.60.77]) by p-emlb02-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Sat, 8 Aug 2009 07:40:58 -0700 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp56.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Sat, 8 Aug 2009 07:40:58 -0700 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 n78Eevd78953; Sat, 8 Aug 2009 07:40:57 -0700 (PDT) (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 n78ETItr046639; Sat, 8 Aug 2009 14:29:18 GMT (envelope-from phil@idle.juniper.net) Message-ID: <200908081429.n78ETItr046639@idle.juniper.net> To: Martin Bjorklund In-Reply-To: <20090731.165527.156056701.mbj@tail-f.com> Date: Sat, 8 Aug 2009 10:29:17 -0400 From: Phil Shafer X-OriginalArrivalTime: 08 Aug 2009 14:40:58.0119 (UTC) FILETIME=[3E036170:01CA1836] MIME-Version: 1.0 Content-Type: text/plain Cc: netconf@ietf.org Subject: Re: [Netconf] lock and commit operations 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, 08 Aug 2009 14:44:34 -0000 Martin Bjorklund writes: >Phil Shafer wrote: >> Andy Bierman writes: >> >Does the lock on candidate have any affect on ? >> >> Absolutely. The lock on config controls the commit. > >This is not obvious so it needs clarification. does not >modify the candidate, so why does a lock on candidate prevent me from >committing? If running is locked it is obvious since running will be >modified by the commit. So to make candidate work correctly, I'd need to lock both candidate and running? This is also not obvious. IMHO we just need to add words that a lock on candidate blocks the commit operation. This is what we do in junos. Thanks, Phil From phil@juniper.net Sat Aug 8 07:52: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 552BC28C0DE for ; Sat, 8 Aug 2009 07:52:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.526 X-Spam-Level: X-Spam-Status: No, score=-6.526 tagged_above=-999 required=5 tests=[AWL=0.073, 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 qS934F8D5hOK for ; Sat, 8 Aug 2009 07:52:02 -0700 (PDT) Received: from exprod7og109.obsmtp.com (exprod7og109.obsmtp.com [64.18.2.171]) by core3.amsl.com (Postfix) with ESMTP id C64BD28C1A1 for ; Sat, 8 Aug 2009 07:52:01 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob109.postini.com ([64.18.6.12]) with SMTP ID DSNKSn2RFUDhGvWa6S5P4uEcGkzpHAPotD+N@postini.com; Sat, 08 Aug 2009 07:52:06 PDT 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; Sat, 8 Aug 2009 07:49:27 -0700 Received: from p-emlb02-sac.jnpr.net ([66.129.254.47]) by p-emfe01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Sat, 8 Aug 2009 07:49:26 -0700 Received: from emailsmtp56.jnpr.net ([172.24.60.77]) by p-emlb02-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Sat, 8 Aug 2009 07:49:26 -0700 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp56.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Sat, 8 Aug 2009 07:49:25 -0700 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 n78EnPd81545; Sat, 8 Aug 2009 07:49:25 -0700 (PDT) (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 n78EbjCL046750; Sat, 8 Aug 2009 14:37:46 GMT (envelope-from phil@idle.juniper.net) Message-ID: <200908081437.n78EbjCL046750@idle.juniper.net> To: Andy Bierman In-Reply-To: <4A745D4F.9070504@netconfcentral.com> Date: Sat, 8 Aug 2009 10:37:45 -0400 From: Phil Shafer X-OriginalArrivalTime: 08 Aug 2009 14:49:25.0634 (UTC) FILETIME=[6C840620:01CA1837] MIME-Version: 1.0 Content-Type: text/plain Cc: NETCONF Subject: Re: [Netconf] :writable-running and :candidate 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, 08 Aug 2009 14:52:03 -0000 Andy Bierman writes: >I asked (in email) how the :candidate and :writable-running >capabilities can possibly be supported on the same agent. >I never got an answer. I believe I answered you, saying that tail-f's sw does this. Thanks, Phil From phil@juniper.net Sat Aug 8 07:54: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 9C96C28C0E8 for ; Sat, 8 Aug 2009 07:54:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.528 X-Spam-Level: X-Spam-Status: No, score=-6.528 tagged_above=-999 required=5 tests=[AWL=0.071, 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 g1tUhL1eOFfO for ; Sat, 8 Aug 2009 07:54:38 -0700 (PDT) Received: from exprod7og102.obsmtp.com (exprod7og102.obsmtp.com [64.18.2.157]) by core3.amsl.com (Postfix) with ESMTP id B99C128C22C for ; Sat, 8 Aug 2009 07:53:49 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob102.postini.com ([64.18.6.12]) with SMTP ID DSNKSn2RgbObzt/FnYZvmiCqvIdCnK8I6/vc@postini.com; Sat, 08 Aug 2009 07:53:54 PDT 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; Sat, 8 Aug 2009 07:52:07 -0700 Received: from p-emlb01-sac.jnpr.net ([66.129.254.46]) by p-emfe01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Sat, 8 Aug 2009 07:52:07 -0700 Received: from emailsmtp56.jnpr.net ([172.24.60.77]) by p-emlb01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Sat, 8 Aug 2009 07:52:06 -0700 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp56.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Sat, 8 Aug 2009 07:52:06 -0700 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 n78Eq5d82163; Sat, 8 Aug 2009 07:52:05 -0700 (PDT) (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 n78EeQGu046784; Sat, 8 Aug 2009 14:40:26 GMT (envelope-from phil@idle.juniper.net) Message-ID: <200908081440.n78EeQGu046784@idle.juniper.net> To: Andy Bierman In-Reply-To: <4A7473F3.5080709@netconfcentral.com> Date: Sat, 8 Aug 2009 10:40:26 -0400 From: Phil Shafer X-OriginalArrivalTime: 08 Aug 2009 14:52:06.0003 (UTC) FILETIME=[CC1A6430:01CA1837] MIME-Version: 1.0 Content-Type: text/plain Cc: NETCONF Subject: Re: [Netconf] partial locking for candidate and startup? 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, 08 Aug 2009 14:54:38 -0000 Andy Bierman writes: >Are there any plans to extend the partial locking >feature to the candidate and startup databases? The opposite. I've asked that explicit language be added to the partial lock draft saying that it is not compatible with :candidate, since partial locking with full commits is a non-starter. Thanks, Phil From andy@netconfcentral.com Sat Aug 8 08:00: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 5579728C246 for ; Sat, 8 Aug 2009 08:00:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.492 X-Spam-Level: X-Spam-Status: No, score=-2.492 tagged_above=-999 required=5 tests=[AWL=0.107, 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 ADJ4kCnXvg-k for ; Sat, 8 Aug 2009 08:00:15 -0700 (PDT) Received: from smtp106.sbc.mail.mud.yahoo.com (smtp106.sbc.mail.mud.yahoo.com [68.142.198.205]) by core3.amsl.com (Postfix) with SMTP id 3D9E328C239 for ; Sat, 8 Aug 2009 08:00:15 -0700 (PDT) Received: (qmail 22284 invoked from network); 8 Aug 2009 15:00:15 -0000 Received: from unknown (HELO ?192.168.0.10?) (andy@67.125.157.61 with plain) by smtp106.sbc.mail.mud.yahoo.com with SMTP; 8 Aug 2009 15:00:14 -0000 X-YMail-OSG: Z71sH1AVM1lJrGm3VhmdVUcotn1zVVIOtjMiYtE2ixuxa1kjDI0gXUo_VbGbPVjCIOizqV89j2VFlis4i5m0xsQcSrlgnZUPww1WejjkLmyIA1HQALYWxgpwTwLWNg67nEE.E4u0oi7mhnoyJZtare5_irdQyiQwYCuCSk_kXLooP1AO7uAS_6m3G88UlUIsYgEPaxC7Vsw8Gtl3phhsUXRz7otvaa8_9.j6c5uphflHiJBMIgnBNODjuqznSPCBa0R1dFEiXYdV8Uw- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4A7D933E.7090307@netconfcentral.com> Date: Sat, 08 Aug 2009 08:01:18 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.22 (X11/20090608) MIME-Version: 1.0 To: Phil Shafer References: <200908081426.n78EQgOs046620@idle.juniper.net> In-Reply-To: <200908081426.n78EQgOs046620@idle.juniper.net> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: netconf@ietf.org Subject: Re: [Netconf] Comments on draft-ietf-netconf-monitoring-06.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: Sat, 08 Aug 2009 15:00:16 -0000 Phil Shafer wrote: > Martin Bjorklund writes: ... >>> (a) should ietf models be under a top-level "/ietf/" container? >> As Andy said this has been discussed and resolved before. Adding this >> hierarchy would just add unnecessay containers. The namespace URI >> provides the context for the top-level node. > > These "unnecessary containers" provide an organizational hierarchy. > Without this, all modules will appear at the top level. This would > be an unbearable bad decision. > > If there are 10 bgp yang modules, how do I say "give me all your > bgp config" to a device? I can't just ask for the > /ietf/protocols/routing/bgp hiearchy and get all 10 overlapping > (augmented) module contents. I brought up the data hierarchy issue about 4 years ago at the Santa Clara interim. Glad to see the issue again. Sorry the situation has only got worse. I agree that we should have top level classes. I am so sick of this ad-hoc, kitchen-sink design focus, that almost anything at all would be better. But /ietf will get huge over time. So each WG should decide its own container names, and not be forced to use a simple formula like ietf-. /ietf-bgp/ /ietf-netconf/ So why don't we have any sort of data organization in NETCONF, so other WGs can follow our good example? Why don't we start organizing and structuring data so we stop setting such a bad example? > ... > Thanks, > Phil > Andy From andy@netconfcentral.com Sat Aug 8 08:08: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 34D3428C241 for ; Sat, 8 Aug 2009 08:08:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.494 X-Spam-Level: X-Spam-Status: No, score=-2.494 tagged_above=-999 required=5 tests=[AWL=0.105, 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 xN+lxhxpT9t5 for ; Sat, 8 Aug 2009 08:08:17 -0700 (PDT) Received: from smtp111.sbc.mail.mud.yahoo.com (smtp111.sbc.mail.mud.yahoo.com [68.142.198.210]) by core3.amsl.com (Postfix) with SMTP id 684BC28C23A for ; Sat, 8 Aug 2009 08:08:17 -0700 (PDT) Received: (qmail 12334 invoked from network); 8 Aug 2009 15:08:20 -0000 Received: from unknown (HELO ?192.168.0.10?) (andy@67.125.157.61 with plain) by smtp111.sbc.mail.mud.yahoo.com with SMTP; 8 Aug 2009 15:08:20 -0000 X-YMail-OSG: NDidAD4VM1k..H_6xxntPAN7q.x2uZTWYFMnaIBo.YmFtDZXjad2IQiOG_qh9lnt4zxLT3h0kIUEaxtR4gnfsEhTBKB.jFs4ldNKqP_5gteoodJI1fPo4un2rengT8VNQFJMBiLe8yFdALZZgTenezTErbjdSyO8kgtKqvXrxU0KJAREtrPlQWlLwDcIbJXkO7.wABgE3qHJ_Kn4S3uyfTgT6pNtVgIBDc.34t9YqntPXe0uHUpHGMjYpTBa0HoblNVb6r2NIoWr_v4- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4A7D9524.30907@netconfcentral.com> Date: Sat, 08 Aug 2009 08:09:24 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.22 (X11/20090608) MIME-Version: 1.0 To: Phil Shafer References: <200908081437.n78EbjCL046750@idle.juniper.net> In-Reply-To: <200908081437.n78EbjCL046750@idle.juniper.net> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: NETCONF Subject: Re: [Netconf] :writable-running and :candidate 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, 08 Aug 2009 15:08:18 -0000 Phil Shafer wrote: > Andy Bierman writes: >> I asked (in email) how the :candidate and :writable-running >> capabilities can possibly be supported on the same agent. >> I never got an answer. > > I believe I answered you, saying that tail-f's sw does this. > I asked for clarifications on the standard, for specific corner-cases that IMO indicate that this combination is not supported by the standard. The thread reached a conclusion that even though any changes made to running will get wiped-out as soon as the candidate is committed, this is how the standard is intended to work. I can't imagine that an operator or NMS developer using :writable-running would reach the same conclusion, but that's their problem -- not an IETF standards problem, right? > Thanks, > Phil > Andy From andy@netconfcentral.com Sat Aug 8 08:18: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 019BD3A6B5B for ; Sat, 8 Aug 2009 08:18:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.328 X-Spam-Level: X-Spam-Status: No, score=-2.328 tagged_above=-999 required=5 tests=[AWL=-0.063, 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 PQZSeuvt4o8o for ; Sat, 8 Aug 2009 08:18:10 -0700 (PDT) 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 669EE3A69B1 for ; Sat, 8 Aug 2009 08:18:10 -0700 (PDT) Received: (qmail 48080 invoked from network); 8 Aug 2009 15:18:12 -0000 Received: from unknown (HELO ?192.168.0.10?) (andy@67.125.157.61 with plain) by smtp126.sbc.mail.sp1.yahoo.com with SMTP; 8 Aug 2009 15:18:12 -0000 X-YMail-OSG: CMkMYzUVM1kIb_pz2hVDBN7Ea5JTJqwqU0b4tK80GLYv6wJ59k2Ny2vudlPiE_UlveacVSMatUQg05ncOOQMOtX4Be05eb3kZRhmO67_JLYv5Z7UCSZ_1lI2tES4jqsFIYWoipE4VhuZ22Hmz.dKPCTKzHV3h7N1Nu0MYHnRzXXyAG4Z5YYFBeBUbfAleaML4.gFyriaUkJmOLfP_IMZz38HvOKIOUKGyC6.SIJ1w4qitUH4c.9tmQKLgVyIKtlE7Iip0lSZXtAdi.U- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4A7D9774.3080100@netconfcentral.com> Date: Sat, 08 Aug 2009 08:19:16 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.22 (X11/20090608) MIME-Version: 1.0 To: Phil Shafer References: <200908081440.n78EeQGu046784@idle.juniper.net> In-Reply-To: <200908081440.n78EeQGu046784@idle.juniper.net> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: NETCONF Subject: Re: [Netconf] partial locking for candidate and startup? 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, 08 Aug 2009 15:18:11 -0000 Phil Shafer wrote: > Andy Bierman writes: >> Are there any plans to extend the partial locking >> feature to the candidate and startup databases? > > The opposite. I've asked that explicit language > be added to the partial lock draft saying that > it is not compatible with :candidate, since partial > locking with full commits is a non-starter. > oh, sorry -- it was a trick question. I agree that it is impossible to make the candidate and startup databases work with partial-locking, and remain compatible with the existing protocol operations. I agree that the partial-lock draft needs to state that it only applies to :writable-running, and only if :startup is not concurrently supported. > Thanks, > Phil > Andy From bertietf@bwijnen.net Sat Aug 8 08:50:44 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 B4FDD3A68F3 for ; Sat, 8 Aug 2009 08:50:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.077 X-Spam-Level: X-Spam-Status: No, score=-5.077 tagged_above=-999 required=5 tests=[AWL=-2.478, 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 JPXGd3YZdWw1 for ; Sat, 8 Aug 2009 08:50:44 -0700 (PDT) Received: from postlady.ripe.net (postlady.ripe.net [193.0.19.65]) by core3.amsl.com (Postfix) with ESMTP id C03403A68DA for ; Sat, 8 Aug 2009 08:50:43 -0700 (PDT) Received: from herring.ripe.net ([193.0.1.203]) by postlady.ripe.net with esmtp (Exim 4.63) (envelope-from ) id 1MZoBo-00074C-Ux; Sat, 08 Aug 2009 17:50:42 +0200 Received: from BWMACBOOK.local (chimp.ripe.net [193.0.1.199]) by herring.ripe.net (Postfix) with ESMTP id C3B262F583; Sat, 8 Aug 2009 17:50:36 +0200 (CEST) Message-ID: <4A7D9ECC.9090101@bwijnen.net> Date: Sat, 08 Aug 2009 17:50:36 +0200 From: "Bert (IETF) Wijnen" User-Agent: Thunderbird 2.0.0.22 (Macintosh/20090605) MIME-Version: 1.0 To: Andy Bierman References: <200908081440.n78EeQGu046784@idle.juniper.net> <4A7D9774.3080100@netconfcentral.com> In-Reply-To: <4A7D9774.3080100@netconfcentral.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-RIPE-Spam-Level: ---- X-RIPE-Signature: 86ab03e524994f79ca2c75a176445dd472a336c0570612cdfe7bcce8ff2461cc Cc: NETCONF Subject: Re: [Netconf] partial locking for candidate and startup? 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, 08 Aug 2009 15:50:44 -0000 Phil and Andy, speaking as a document shepherd for the parial lock doc, pls check the current revision of the doc. I do not think that it is stated as strongly as you suggest below. Yet I believe you did not object to the current text, neither during WG, nor during IETF Last Calls. I just want to make sure we do not have text that would be objectionable to some of our main contributers. I prefer not to have to open the complete debate again. It is on IESG agenda for coming thursday. I'd like it to pass by that date. Bert Andy Bierman wrote: > Phil Shafer wrote: > >> Andy Bierman writes: >> >>> Are there any plans to extend the partial locking >>> feature to the candidate and startup databases? >>> >> The opposite. I've asked that explicit language >> be added to the partial lock draft saying that >> it is not compatible with :candidate, since partial >> locking with full commits is a non-starter. >> >> > > oh, sorry -- it was a trick question. > I agree that it is impossible to make the candidate > and startup databases work with partial-locking, > and remain compatible with the existing protocol operations. > > I agree that the partial-lock draft needs to state > that it only applies to :writable-running, and only > if :startup is not concurrently supported. > > > >> Thanks, >> Phil >> >> > > Andy > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf > > > From phil@juniper.net Sat Aug 8 22:06:43 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 52A4B3A69A1 for ; Sat, 8 Aug 2009 22:06:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.533 X-Spam-Level: X-Spam-Status: No, score=-6.533 tagged_above=-999 required=5 tests=[AWL=0.066, 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 wPyyKU7fwPpi for ; Sat, 8 Aug 2009 22:06:42 -0700 (PDT) Received: from exprod7og122.obsmtp.com (exprod7og122.obsmtp.com [64.18.2.22]) by core3.amsl.com (Postfix) with ESMTP id B65203A6CAA for ; Sat, 8 Aug 2009 22:06:41 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob122.postini.com ([64.18.6.12]) with SMTP ID DSNKSn5ZYuuga+0HQuPeGv+bdSxwfbZeOwAZ@postini.com; Sat, 08 Aug 2009 22:06:46 PDT 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; Sat, 8 Aug 2009 22:04:10 -0700 Received: from p-emlb01-sac.jnpr.net ([66.129.254.46]) by p-emfe01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Sat, 8 Aug 2009 22:04:10 -0700 Received: from emailsmtp55.jnpr.net ([172.24.18.132]) by p-emlb01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Sat, 8 Aug 2009 22:04:09 -0700 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp55.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Sat, 8 Aug 2009 22:04:09 -0700 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 n79548d38630; Sat, 8 Aug 2009 22:04:08 -0700 (PDT) (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 n794qSUR050060; Sun, 9 Aug 2009 04:52:28 GMT (envelope-from phil@idle.juniper.net) Message-ID: <200908090452.n794qSUR050060@idle.juniper.net> To: Juergen Schoenwaelder In-Reply-To: <20090804144838.GA962@elstar.local> Date: Sun, 9 Aug 2009 00:52:27 -0400 From: Phil Shafer X-OriginalArrivalTime: 09 Aug 2009 05:04:09.0022 (UTC) FILETIME=[D3CC05E0:01CA18AE] MIME-Version: 1.0 Content-Type: text/plain Cc: Netconf Subject: Re: [Netconf] Fw: Database Architecture OK or NOT-OK? 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, 09 Aug 2009 05:06:43 -0000 Juergen Schoenwaelder writes: >It is not clear to me why changes to running can't happen while >candidate is locked. It is probably not terribly useful but it is >unclear why it must be forbidden. Can you explain? Because it makes locking candidate pointless. The model is: lock candidate make change commit change unlock candidate This sequence should ensure that my changes are applied atomically and in isolation to the device. If someone can change running while I've locked candidate, then I can't commit without trashing those changes. Thanks, Phil From phil@juniper.net Sat Aug 8 22: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 2EE583A6AB8 for ; Sat, 8 Aug 2009 22:12:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.535 X-Spam-Level: X-Spam-Status: No, score=-6.535 tagged_above=-999 required=5 tests=[AWL=0.064, 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 B7Qzdd9yM0ep for ; Sat, 8 Aug 2009 22:12:37 -0700 (PDT) Received: from exprod7og123.obsmtp.com (exprod7og123.obsmtp.com [64.18.2.24]) by core3.amsl.com (Postfix) with ESMTP id 73C963A68BE for ; Sat, 8 Aug 2009 22:12:36 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob123.postini.com ([64.18.6.12]) with SMTP ID DSNKSn5axdrN6nF2K2TpY/bTdnavY58gCT6w@postini.com; Sat, 08 Aug 2009 22:12:41 PDT 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; Sat, 8 Aug 2009 22:09:39 -0700 Received: from p-emlb02-sac.jnpr.net ([66.129.254.47]) by p-emfe01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Sat, 8 Aug 2009 22:09:39 -0700 Received: from emailsmtp55.jnpr.net ([172.24.18.132]) by p-emlb02-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Sat, 8 Aug 2009 22:09:38 -0700 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp55.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Sat, 8 Aug 2009 22:09:38 -0700 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 n7959bd40006; Sat, 8 Aug 2009 22:09:37 -0700 (PDT) (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 n794vvv7050103; Sun, 9 Aug 2009 04:57:57 GMT (envelope-from phil@idle.juniper.net) Message-ID: <200908090457.n794vvv7050103@idle.juniper.net> To: Juergen Schoenwaelder In-Reply-To: <20090804184136.GC1038@elstar.local> Date: Sun, 9 Aug 2009 00:57:57 -0400 From: Phil Shafer X-OriginalArrivalTime: 09 Aug 2009 05:09:38.0066 (UTC) FILETIME=[97EC2720:01CA18AF] MIME-Version: 1.0 Content-Type: text/plain Cc: Netconf Subject: Re: [Netconf] Fw: Database Architecture OK or NOT-OK? 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, 09 Aug 2009 05:12:38 -0000 Juergen Schoenwaelder writes: >I still find it surprising that I have to do the discard-changes() >before lock('candidate') but Phil strongly believes that failing >lock('candidate') if 'candidate' != 'running' is the correct way of >doing things. I strongly believe that you should not do a discard-changes before locking, since this means you may be discard changes that have not been discarded or committed. If someone has outstanding changes to the database but did not lock it, then you know that either (a) someone crazy is playing with your config, or (b) something very wrong has happened. Blowing away the changes and plowing ahead isn't the proper action for either case. I also strongly believe that allowing a lock while these outstanding changes exist is very bad. Thanks, Phil From Washam.Fan@huaweisymantec.com Sun Aug 9 01:14: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 5963C3A6A04 for ; Sun, 9 Aug 2009 01:14:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.364 X-Spam-Level: * X-Spam-Status: No, score=1.364 tagged_above=-999 required=5 tests=[BAYES_20=-0.74, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id avqBFKNXQwwb for ; Sun, 9 Aug 2009 01:14:14 -0700 (PDT) Received: from mta1.huaweisymantec.com (unknown [218.17.155.14]) by core3.amsl.com (Postfix) with ESMTP id 8A73B3A683B for ; Sun, 9 Aug 2009 01:14:14 -0700 (PDT) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-disposition: inline Content-type: text/plain; charset=us-ascii Received: from hstml02-in.huaweisymantec.com ([172.26.3.41]) by hstga01-in.huaweisymantec.com (Sun Java(tm) System Messaging Server 6.3-8.03 (built Apr 24 2009; 32bit)) with ESMTP id <0KO300GSSO6ZMZ00@hstga01-in.huaweisymantec.com> for netconf@ietf.org; Sun, 09 Aug 2009 16:13:47 +0800 (CST) Received: from huaweisymantec.com ([127.0.0.1]) by hstml02-in.huaweisymantec.com (Sun Java(tm) System Messaging Server 6.3-8.03 (built Apr 24 2009; 32bit)) with ESMTP id <0KO300LBTO6YTO10@hstml02-in.huaweisymantec.com> for netconf@ietf.org; Sun, 09 Aug 2009 16:13:47 +0800 (CST) Received: from [117.79.65.106] by hstml02-in.huaweisymantec.com (mshttpd); Sun, 09 Aug 2009 16:13:46 +0800 From: WashamFan To: Phil Shafer Message-id: Date: Sun, 09 Aug 2009 16:13:46 +0800 X-Mailer: Sun Java(tm) System Messenger Express 6.3-8.03 (built Apr 24 2009; 32bit) Content-language: en X-Accept-Language: en Priority: normal In-reply-to: <200908090457.n794vvv7050103@idle.juniper.net> References: <20090804184136.GC1038@elstar.local> <200908090457.n794vvv7050103@idle.juniper.net> Cc: Netconf Subject: Re: [Netconf] Fw: Database Architecture OK or NOT-OK? 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, 09 Aug 2009 08:14:15 -0000 > Juergen Schoenwaelder writes: > >I still find it surprising that I have to do the discard-changes() > >before lock('candidate') but Phil strongly believes that failing > >lock('candidate') if 'candidate' != 'running' is the correct way of > >doing things. > > I strongly believe that you should not do a discard-changes before > locking, since this means you may be discard changes that have not > been discarded or committed. If someone has outstanding changes > to the database but did not lock it, then you know that either (a) > someone crazy is playing with your config, or (b) something very > wrong has happened. Blowing away the changes and plowing ahead > isn't the proper action for either case. So what should be done when I want to lock the "dirty" candidate config? > I also strongly believe that allowing a lock while these > outstanding changes exist is very bad. That is also what the current text believes. It says you can not grab a lock on "dirty" candidate. washam > Thanks, > Phil From andy@netconfcentral.com Sun Aug 9 07:01: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 9CEC73A6A42 for ; Sun, 9 Aug 2009 07:01:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.327 X-Spam-Level: X-Spam-Status: No, score=-2.327 tagged_above=-999 required=5 tests=[AWL=-0.062, 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 o0HO3pWyrEV8 for ; Sun, 9 Aug 2009 07:01:55 -0700 (PDT) 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 EA3A13A67B0 for ; Sun, 9 Aug 2009 07:01:55 -0700 (PDT) Received: (qmail 72224 invoked from network); 9 Aug 2009 14:01:56 -0000 Received: from unknown (HELO ?192.168.0.10?) (andy@67.125.157.61 with plain) by smtp127.sbc.mail.sp1.yahoo.com with SMTP; 9 Aug 2009 14:01:56 -0000 X-YMail-OSG: SRo0UhEVM1ls0HM4cVvkFH6Tmur.ikANCh0SU14qvXQLeJhVHvUIC78FLcPBEbFEUbuHkUQOGgF6atqFrxcYNtaxYa6VH2NxbYvg7CzX9bQjCAlEsOI1aoLtI36AxAfhXo28V224SiqfGyEvOrQJfwcmeWYaixd_Ehq2mF6zxHbqvyo7lt1dgwBKwOVgmwJoQEGX_2RKxXcv6ZsWwPJ821Pdo7Xk28KcAcZQPVzSCISfPeFu8pTl7FV8VLTgQcgiWg1QSo6UXmCvTTDo9teZZeSY4MT_g60qPB32mmL66LQR1_Vci_s- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4A7ED69F.9060602@netconfcentral.com> Date: Sun, 09 Aug 2009 07:01:03 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.22 (X11/20090608) MIME-Version: 1.0 To: Phil Shafer References: <200908090452.n794qSUR050060@idle.juniper.net> In-Reply-To: <200908090452.n794qSUR050060@idle.juniper.net> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Netconf Subject: Re: [Netconf] Fw: Database Architecture OK or NOT-OK? 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, 09 Aug 2009 14:01:56 -0000 Phil Shafer wrote: > Juergen Schoenwaelder writes: >> It is not clear to me why changes to running can't happen while >> candidate is locked. It is probably not terribly useful but it is >> unclear why it must be forbidden. Can you explain? > > Because it makes locking candidate pointless. The model is: > This needs to be resolved. The operation clearly alters the running config so a lock on running will block it. It is not clear that a lock on candidate blocks . It clearly blocks the operations that write to candidate. It is not clear that writes to candidate. It does not. The operation is supposed to leave the candidate untouched, so why does the lock on candidate affect ? > lock candidate > make change > commit change > unlock candidate > > This sequence should ensure that my changes are applied > atomically and in isolation to the device. If someone > can change running while I've locked candidate, then > I can't commit without trashing those changes. > > Thanks, > Phil > Andy From andy@netconfcentral.com Sun Aug 9 08:19: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 A497F3A6AE1 for ; Sun, 9 Aug 2009 08:19:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.493 X-Spam-Level: X-Spam-Status: No, score=-2.493 tagged_above=-999 required=5 tests=[AWL=0.106, 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 LJzNXbKaqzcT for ; Sun, 9 Aug 2009 08:19:38 -0700 (PDT) Received: from n20.bullet.mail.mud.yahoo.com (n20.bullet.mail.mud.yahoo.com [68.142.206.147]) by core3.amsl.com (Postfix) with SMTP id 3C8303A6C7A for ; Sun, 9 Aug 2009 08:19:19 -0700 (PDT) Received: from [209.191.108.96] by n20.bullet.mail.mud.yahoo.com with NNFMP; 09 Aug 2009 15:19:21 -0000 Received: from [68.142.201.251] by t3.bullet.mud.yahoo.com with NNFMP; 09 Aug 2009 15:19:21 -0000 Received: from [127.0.0.1] by omp412.mail.mud.yahoo.com with NNFMP; 09 Aug 2009 15:19:20 -0000 X-Yahoo-Newman-Id: 999055.1777.bm@omp412.mail.mud.yahoo.com Received: (qmail 45547 invoked from network); 9 Aug 2009 15:19:20 -0000 Received: from unknown (HELO ?192.168.0.10?) (andy@67.125.157.61 with plain) by smtp109.sbc.mail.sp1.yahoo.com with SMTP; 9 Aug 2009 15:19:20 -0000 X-YMail-OSG: bvDWnFUVM1m.xU15v66q7STsj_CXFvU64oEVmUrvtfP0tOivDNAAuTz016hUML4cW_jfy_GHZtTWvKHiaxoSTyWLR6eIq_NhlgreXWc2YQEzEKmVKN25F1pJc19jNJRv1LlyGVt6qFNmobmVAF4PX7_8NpxTpGLJGE3pCJVCRt72ZkdJA36Lh_D7TbDEyHt2XwDC.1S9YJGwVzTf1sG9.BzWfDO_yJ0WrGO7N_kxKyp90SX_kjU- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4A7EE8C6.5080706@netconfcentral.com> Date: Sun, 09 Aug 2009 08:18:30 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.22 (X11/20090608) MIME-Version: 1.0 To: NETCONF Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [Netconf] validate-1.1 capability 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, 09 Aug 2009 15:19:39 -0000 Hi, The validate-1.1 capability is somewhat broken. I would prefer to see all the validate capability be mandatory (including rollback-on-error), but this would mean a new protocol version. It is trivial to implement test-only, but it is only available if the agent implements test-then-set and the operation. As Balazs pointed out many times already, the fact that the manager MUST NOT provide this parameter unless :validate is supported is really fragile. Also, I have pointed out many times that the default of 'test-then-set' is totally wrong. It makes no difference on running, but on the candidate, it will disrupt incremental editing. The default should always be 'set'. (test-then-set forces the manager to provide all the related edits at once, but that is totally contrary to the purpose of the candidate config). I want to change 4741bis to reflect this behavior, except I think micro-partitioning the parameters for various operations in arbitrary ways needs to stop. So I don't want to fix it with a band-aid like this validate-1.1 capability. This design approach will be a disaster for NMS developers within a few years. By insisting that the protocol version stay the same, the WG is actually making NETCONF harder to use for NMS developers, not easier. Andy From andy@netconfcentral.com Sun Aug 9 09:05: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 A187A3A689C for ; Sun, 9 Aug 2009 09:05:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.195 X-Spam-Level: X-Spam-Status: No, score=-2.195 tagged_above=-999 required=5 tests=[AWL=-0.196, BAYES_00=-2.599, J_CHICKENPOX_43=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 CLiqOeZXojoe for ; Sun, 9 Aug 2009 09:05:40 -0700 (PDT) Received: from smtp107.sbc.mail.mud.yahoo.com (smtp107.sbc.mail.mud.yahoo.com [68.142.198.206]) by core3.amsl.com (Postfix) with SMTP id 67A6D3A6878 for ; Sun, 9 Aug 2009 09:05:40 -0700 (PDT) Received: (qmail 50864 invoked from network); 9 Aug 2009 15:59:04 -0000 Received: from unknown (HELO ?192.168.0.10?) (andy@67.125.157.61 with plain) by smtp107.sbc.mail.mud.yahoo.com with SMTP; 9 Aug 2009 15:59:04 -0000 X-YMail-OSG: 7fTN.3cVM1k8lT1WVD1mGfwfWVXeV_SRvFQUGVcV7YB8lKshsTG_xqxdfYSDDtiVRJpGI8gHI.fcxtw.FdcYwc2yJssyMWjyjbLJ8nS4g8fDzxwyMpQO9U20l3ykwT1azupLQPHgrfq_OCOuXh2EtfDEt_iRaT8poR6ZcVuU8X2N07pbOt217LCm6AWeffqu.Uu2j6P6tGDAo35cHgcOQAvrUV7v8KQSzDmXCHfEpY5qreljywm5moZQpd2IM9IxTvn7ISkgCV5OH6o- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4A7EF28E.2040502@netconfcentral.com> Date: Sun, 09 Aug 2009 09:00:14 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.22 (X11/20090608) MIME-Version: 1.0 To: NETMOD Working Group , NETCONF Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [Netconf] staying in synch on data model discovery 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, 09 Aug 2009 16:05:40 -0000 Hi, I would like to see the NETCONF and NETMOD WGs act more like they play for the same team regarding YANG and all the YANG data models under development. I mostly care about the ietf-netconf-state data model to use the get-schema() operation with YANG. If others want XSD and RNG instead, then that's extra credit, but full support for YANG is a must-have. YANG modules, submodules, and deviation modules all need to be listed in the and retrievable with . However, deviations have no revision that is advertised, yet they clearly have a revision-date just like any other YANG module. This is somewhere between confusing and broken. The field in the operation is mandatory. It should be optional, and if missing, then the agent will pick whatever revision it wants (usually there will just be 1 to pick from). The field in the operation is mandatory. It should be optional, and the default should be 'YANG'. IMO, the use of capabilities instead of YANG features needs to stop. Even more, ALL the data models under way in the NETCONF WG should wait for YANG, and use YANG features, not protocol capabilities to achieve. That will eliminate the possibility that there can be 16 valid variants of the same leaf,and will help start out with a coherent set of YANG modules using the same data types (e.g., ip-address issue). I think the node should have another leaf: leaf moduleType { description "The type of data model file for this schema entry."; type enumeration { enum module { description "Indicates this entry is for a main module."; } enum submodule { description "Indicates this entry is for a sub-module."; } enum deviation { description "Indicates this entry is for a deviation module."; } enum other { description "Indicates this entry is for some other type of module."; } } } This will help operators understand what all the 'extra' entries are for, and allow better filtering of the subtree. Andy From andy@netconfcentral.com Sun Aug 9 09:35: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 DCAD93A6AA3 for ; Sun, 9 Aug 2009 09:35:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.492 X-Spam-Level: X-Spam-Status: No, score=-2.492 tagged_above=-999 required=5 tests=[AWL=0.107, 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 E8zKnXoP6zgQ for ; Sun, 9 Aug 2009 09:35:15 -0700 (PDT) Received: from smtp106.sbc.mail.mud.yahoo.com (smtp106.sbc.mail.mud.yahoo.com [68.142.198.205]) by core3.amsl.com (Postfix) with SMTP id B4AD53A6824 for ; Sun, 9 Aug 2009 09:35:15 -0700 (PDT) Received: (qmail 16474 invoked from network); 9 Aug 2009 16:35:17 -0000 Received: from unknown (HELO ?192.168.0.10?) (andy@67.125.157.61 with plain) by smtp106.sbc.mail.mud.yahoo.com with SMTP; 9 Aug 2009 16:35:17 -0000 X-YMail-OSG: FFt_BYsVM1nWhfEFN2q6Wrmya7Zlyklffpxud8gM_1nsHayhzIrcVekaL_uFmf.0d6uGaWb.msX4gADAlOSPnK3mG_WLrb.I6ngyDy0kFJhQh0IHrj.R14aosm06fKvzRNVIIn3DewzWiNhMcqDUbnrilvTWrJ2KNcOgtoZ70lD97nnKyNs0BMjohCykeaYZ_QCTL_17SFWJJ6Q2OH5evasqV1JAQVpqdDvjpxWijFytz41Bt_T2.Shmwy891W3OhO6KOiJJl_BVCKeP0FAWHDCyaOVAT__3HLXnGEOWdD1aZBw.DrHTlNX2nhknB5RG4VQH0Ax3wkNZs3d_nxI- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4A7EFB0C.3010801@netconfcentral.com> Date: Sun, 09 Aug 2009 09:36:28 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.22 (X11/20090608) MIME-Version: 1.0 To: "Bert (IETF) Wijnen" References: <200908081440.n78EeQGu046784@idle.juniper.net> <4A7D9774.3080100@netconfcentral.com> <4A7D9ECC.9090101@bwijnen.net> In-Reply-To: <4A7D9ECC.9090101@bwijnen.net> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: NETCONF Subject: Re: [Netconf] partial locking for candidate and startup? 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, 09 Aug 2009 16:35:16 -0000 Bert (IETF) Wijnen wrote: > Phil and Andy, speaking as a document shepherd for the parial lock doc, > pls check the current revision of the doc. I do not think that it > is stated as strongly as you suggest below. Yet I believe you did not > object to the current text, neither during WG, nor during IETF Last Calls. > > I just want to make sure we do not have text that would be objectionable > to some of our main contributers. I prefer not to have to open the complete > debate again. > > It is on IESG agenda for coming thursday. I'd like it to pass by that date. > I agree with Phil that it is harmful to interoperability to even suggest that partial locking works on the candidate config. I have no problem with limiting the scope of :partial-lock to the 1 use-case where it is most needed. Only high volume 'provisioning' applications really need partial locking at all. Only those platforms (or the very small platforms) are likely to choose the 'SQL-like' database option and just support :writable-running. My concern (and perhaps Phil's concern) is well-founded. We have seen over and over in the NETCONF work that a sloppy sentence written 4 years ago can turn into all kinds of implementation requirements that were never intended in the first place. Now there will be normative text that piles on a new capability on top of 2 old ones, in a manner that clearly does not work. We have a global candidate config in NETCONF and I prefer that it stay that way. I don't want any standard text anywhere that even suggests that the candidate database tracks separate change-sets per session, and commits them per-session. For candidate, there is no partial-lock, partial-commit, or partial-discard-changes, and it should stay that way. Except, now there will be a partial-lock. I object to the text in 2.6.1 and 2.6.3. I cannot implement :partial-lock because of these additional requirements that do not actually work. Nobody is going to take out :candidate and :startup to support this new capability. I cannot allow partial locking on either candidate or startup, so I cannot conform to the standard, even though I could implement the only relevant portion of the document that works. I do not think any agent implementation can support these requirements and still support the RFC 4741 protocol operations in a robust and pilot-error-resistant manner. In case I am not clear enough, Bert, I strongly object to the publication of this document in its current form. > Bert Andy > > > > Andy Bierman wrote: >> Phil Shafer wrote: >> >>> Andy Bierman writes: >>> >>>> Are there any plans to extend the partial locking >>>> feature to the candidate and startup databases? >>>> >>> The opposite. I've asked that explicit language >>> be added to the partial lock draft saying that >>> it is not compatible with :candidate, since partial >>> locking with full commits is a non-starter. >>> >>> >> >> oh, sorry -- it was a trick question. >> I agree that it is impossible to make the candidate >> and startup databases work with partial-locking, >> and remain compatible with the existing protocol operations. >> >> I agree that the partial-lock draft needs to state >> that it only applies to :writable-running, and only >> if :startup is not concurrently supported. >> >> >> >>> Thanks, >>> Phil >>> >>> >> >> Andy >> _______________________________________________ >> Netconf mailing list >> Netconf@ietf.org >> https://www.ietf.org/mailman/listinfo/netconf >> >> >> > > From j.schoenwaelder@jacobs-university.de Sun Aug 9 12:05: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 266593A6CFA for ; Sun, 9 Aug 2009 12:05:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.279 X-Spam-Level: X-Spam-Status: No, score=-1.279 tagged_above=-999 required=5 tests=[AWL=-0.889, 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 SO+9zYL-tgcd for ; Sun, 9 Aug 2009 12:05:11 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 5B63E3A6CBE for ; Sun, 9 Aug 2009 12:05:10 -0700 (PDT) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 09958C0019; Sun, 9 Aug 2009 21:05:13 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius4.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id rlgkA2SJIRNt; Sun, 9 Aug 2009 21:05:12 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 9C2D6C0014; Sun, 9 Aug 2009 21:05:11 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 8642EB7FEB2; Sun, 9 Aug 2009 21:05:10 +0200 (CEST) Date: Sun, 9 Aug 2009 21:05:10 +0200 From: Juergen Schoenwaelder To: Andy Bierman Message-ID: <20090809190510.GB4359@elstar.local> Mail-Followup-To: Andy Bierman , Phil Shafer , "netconf@ietf.org" References: <200908081426.n78EQgOs046620@idle.juniper.net> <4A7D933E.7090307@netconfcentral.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4A7D933E.7090307@netconfcentral.com> User-Agent: Mutt/1.5.19 (2009-01-05) Cc: "netconf@ietf.org" Subject: Re: [Netconf] Comments on draft-ietf-netconf-monitoring-06.txt 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, 09 Aug 2009 19:05:12 -0000 On Sat, Aug 08, 2009 at 05:01:18PM +0200, Andy Bierman wrote: > But /ietf will get huge over time. So each WG should > decide its own container names, and not be forced to > use a simple formula like ietf-. > > /ietf-bgp/ > /ietf-netconf/ > > So why don't we have any sort of data organization in NETCONF, > so other WGs can follow our good example? Why > don't we start organizing and structuring data > so we stop setting such a bad example? Using is a choice but IMHO not a very good choice; WGs are means to organize work and they not necessarily provide good and organized and long lasting names we are looking for. /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 Sun Aug 9 12:16: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 033143A6D45 for ; Sun, 9 Aug 2009 12:16:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.494 X-Spam-Level: X-Spam-Status: No, score=-2.494 tagged_above=-999 required=5 tests=[AWL=0.105, 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 Mqoe7zlOpytn for ; Sun, 9 Aug 2009 12:16:51 -0700 (PDT) Received: from smtp113.sbc.mail.mud.yahoo.com (smtp113.sbc.mail.mud.yahoo.com [68.142.198.212]) by core3.amsl.com (Postfix) with SMTP id 2DA5A3A6D40 for ; Sun, 9 Aug 2009 12:16:51 -0700 (PDT) Received: (qmail 55167 invoked from network); 9 Aug 2009 19:16:51 -0000 Received: from unknown (HELO ?192.168.0.10?) (andy@67.125.157.61 with plain) by smtp113.sbc.mail.mud.yahoo.com with SMTP; 9 Aug 2009 19:16:51 -0000 X-YMail-OSG: K3n1DIAVM1k_3dISm478y3XTa5WpL1xIuZNKG6R9QORWK1mAHwHZ1Y1xBGRBPotya6ux0zBQlGoYiLbHl7OjoIGzyXkAD6fUqppxFeqE1lX5z4WgqCNXKyUfcZATEvuSIkP0kFflpnFgLiDvADpMUw8zQFf_n4OrRyH1mE_jpUUn3UM8i0j.J5SAACHz7nIyloWNB7ehdYZShmr7Ac8EFCXX2MQS_cOayjq3b6Kces8ux4a6Z9l02FfO0R9Q1shmmNC9IkOktYyW3vQ- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4A7F20EB.2010002@netconfcentral.com> Date: Sun, 09 Aug 2009 12:18:03 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.22 (X11/20090608) MIME-Version: 1.0 To: Andy Bierman , Phil Shafer , "netconf@ietf.org" References: <200908081426.n78EQgOs046620@idle.juniper.net> <4A7D933E.7090307@netconfcentral.com> <20090809190510.GB4359@elstar.local> In-Reply-To: <20090809190510.GB4359@elstar.local> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [Netconf] Comments on draft-ietf-netconf-monitoring-06.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: Sun, 09 Aug 2009 19:16:52 -0000 Juergen Schoenwaelder wrote: > On Sat, Aug 08, 2009 at 05:01:18PM +0200, Andy Bierman wrote: > >> But /ietf will get huge over time. So each WG should >> decide its own container names, and not be forced to >> use a simple formula like ietf-. >> >> /ietf-bgp/ >> /ietf-netconf/ >> >> So why don't we have any sort of data organization in NETCONF, >> so other WGs can follow our good example? Why >> don't we start organizing and structuring data >> so we stop setting such a bad example? > > Using is a choice but IMHO not a very good choice; WGs are > means to organize work and they not necessarily provide good and > organized and long lasting names we are looking for. > but this is protocol name, not WG name. > /js > Andy From j.schoenwaelder@jacobs-university.de Sun Aug 9 13:54: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 8CE133A6C5F for ; Sun, 9 Aug 2009 13:54:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.198 X-Spam-Level: X-Spam-Status: No, score=-2.198 tagged_above=-999 required=5 tests=[AWL=0.051, 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 Y3IPqlENxe4s for ; Sun, 9 Aug 2009 13:54:32 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id D05583A6C1D for ; Sun, 9 Aug 2009 13:54:31 -0700 (PDT) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 3864AC0016; Sun, 9 Aug 2009 22:54:35 +0200 (CEST) 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 Y2PvRFv1sSWe; Sun, 9 Aug 2009 22:54:34 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id F1BF7C0014; Sun, 9 Aug 2009 22:54:33 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id D71A6B800BA; Sun, 9 Aug 2009 22:54:32 +0200 (CEST) Date: Sun, 9 Aug 2009 22:54:32 +0200 From: Juergen Schoenwaelder To: Phil Shafer Message-ID: <20090809205432.GA4430@elstar.local> Mail-Followup-To: Phil Shafer , Andy Bierman , Netconf References: <20090804184136.GC1038@elstar.local> <200908090457.n794vvv7050103@idle.juniper.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200908090457.n794vvv7050103@idle.juniper.net> User-Agent: Mutt/1.5.19 (2009-01-05) Cc: Netconf Subject: Re: [Netconf] Fw: Database Architecture OK or NOT-OK? 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, 09 Aug 2009 20:54:33 -0000 On Sun, Aug 09, 2009 at 06:57:57AM +0200, Phil Shafer wrote: > Juergen Schoenwaelder writes: > >I still find it surprising that I have to do the discard-changes() > >before lock('candidate') but Phil strongly believes that failing > >lock('candidate') if 'candidate' != 'running' is the correct way of > >doing things. > > I strongly believe that you should not do a discard-changes before > locking, since this means you may be discard changes that have not > been discarded or committed. If someone has outstanding changes > to the database but did not lock it, then you know that either (a) > someone crazy is playing with your config, or (b) something very > wrong has happened. Blowing away the changes and plowing ahead > isn't the proper action for either case. > > I also strongly believe that allowing a lock while these > outstanding changes exist is very bad. I do not see how this works with writeable-running. See this sequence with three sessions S1-S3: S1: ... S1: discard-changes() S1: close-session() S2: lock(running) S2: edit-config(running, ...) S2: unlock(running) S3: lock(candidate) S3: edit-config(candidate, ...) S3: commit() S3: unlock(candidate) Do you blow away changes that were made to running? Or would an implementation have to detect that candidate is dirty due to changes made to running? Since candidate is a shared buffer, how can I every use discard-changes() in a save way without having a proper lock? RFC 4741 discusses in section 8.3.1 that candidate is a buffer shared among multiple sessions and it gives the following advise: "It is therefore prudent for a client to lock the candidate configuration before modifying it." You seem to want to protect applications that do not use locks properly and I wonder how this is ever going to work. Each invocation of discard-changes() simply discards all changes and I can never be sure that I really know what the change set is I discard - unless I use locks. So for me, any invocation of discard-changes() outside a lock is broken - whatever your intentions are. But then I am not allowed to obtain locks in certain situations and you do not want me to use discard-changes() either. In other words, a session that causes candidate to be dirty (and see above that it is not clear what dirty means with :writable-running) and goes away will cause all other well written applications to stop working. Concrete question to you: Does the Junos CLI use locks or only when specifically asked to use locks? /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From Tomasz.Mikolajczyk@s3group.com Mon Aug 10 00:20: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 5D61A3A694D for ; Mon, 10 Aug 2009 00:20:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.693 X-Spam-Level: * X-Spam-Status: No, score=1.693 tagged_above=-999 required=5 tests=[AWL=-1.207, BAYES_40=-0.185, HELO_EQ_PL=1.135, HOST_EQ_PL=1.95] 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 mL5pOQJOXr+d for ; Mon, 10 Aug 2009 00:20:00 -0700 (PDT) Received: from ormo.s3group.com.pl (ormo.s3group.com.pl [212.160.116.194]) by core3.amsl.com (Postfix) with ESMTP id 525623A6A63 for ; Mon, 10 Aug 2009 00:19:59 -0700 (PDT) Received: from exwro.wroclaw.ad.s3group.com (exwro.wroclaw.s3group.com [192.168.88.33]) by ormo.s3group.com.pl with ESMTP id n7A7JxId014559 for ; Mon, 10 Aug 2009 09:19:59 +0200 Received: from [192.168.88.87] ([192.168.88.87]) by exwro.wroclaw.ad.s3group.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 10 Aug 2009 09:19:58 +0200 Message-ID: <4A7FCA1E.70105@s3group.com> Date: Mon, 10 Aug 2009 09:19:58 +0200 From: Tomasz Mikolajczyk Organization: Silicon & Software Systems User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Netconf References: <200908090452.n794qSUR050060@idle.juniper.net> In-Reply-To: <200908090452.n794qSUR050060@idle.juniper.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 10 Aug 2009 07:19:58.0810 (UTC) FILETIME=[F7DCBBA0:01CA198A] X-Scanner: InterScan AntiVirus for Sendmail X-Filter-Version: 1.11,S3-1.6 (ormo.s3group.com.pl) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.0 (ormo.s3group.com.pl [212.160.116.194]); Mon, 10 Aug 2009 09:20:01 +0200 (CEST) Subject: Re: [Netconf] Fw: Database Architecture OK or NOT-OK? 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, 10 Aug 2009 07:20:01 -0000 Hi, Phil Shafer wrote: > Juergen Schoenwaelder writes: >> It is not clear to me why changes to running can't happen while >> candidate is locked. It is probably not terribly useful but it is >> unclear why it must be forbidden. Can you explain? > > Because it makes locking candidate pointless. The model is: > > lock candidate > make change > commit change > unlock candidate > > This sequence should ensure that my changes are applied > atomically and in isolation to the device. I don't agree. That's not guarantee atomicity! What if a management system losses a connection with a managed device in the middle of commit? Management system (NETCONF agent) cannot guarantee atomicity on its own. Device must support atomic operations and transactions. Regards, Tomasz Mikolajczyk The information contained in this e-mail and in any attachments is confidential and is designated solely for the attention of the intended recipient(s). If you are not an intended recipient, you must not use, disclose, copy, distribute or retain this e-mail or any part thereof. If you have received this e-mail in error, please notify the sender by return e-mail and delete all copies of this e-mail from your computer system(s). Please direct any additional queries to: communications@s3group.com. Thank You. Silicon and Software Systems Limited. Registered in Ireland no. 378073. Registered Office: South County Business Park, Leopardstown, Dublin 18 From dromasca@avaya.com Mon Aug 10 02:17: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 613943A6D5B for ; Mon, 10 Aug 2009 02:17:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.419 X-Spam-Level: X-Spam-Status: No, score=-2.419 tagged_above=-999 required=5 tests=[AWL=0.180, 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 ZFR+54R2bXF7 for ; Mon, 10 Aug 2009 02:17:10 -0700 (PDT) Received: from co300216-co-outbound.net.avaya.com (co300216-co-outbound.net.avaya.com [198.152.13.100]) by core3.amsl.com (Postfix) with ESMTP id 9BC013A6D96 for ; Mon, 10 Aug 2009 02:17:10 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.43,352,1246852800"; d="scan'208";a="179506307" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by co300216-co-outbound.net.avaya.com with ESMTP; 10 Aug 2009 05:17:13 -0400 Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.13]) by co300216-co-erhwest-out.avaya.com with ESMTP; 10 Aug 2009 05:17:13 -0400 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, 10 Aug 2009 11:16:55 +0200 Message-ID: In-Reply-To: <4A7F20EB.2010002@netconfcentral.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Netconf] Comments on draft-ietf-netconf-monitoring-06.txt Thread-Index: AcoZJfg0bfEXy1l4SeOh0F4PJUCPZwAdQjHA References: <200908081426.n78EQgOs046620@idle.juniper.net><4A7D933E.7090307@netconfcentral.com><20090809190510.GB4359@elstar.local> <4A7F20EB.2010002@netconfcentral.com> From: "Romascanu, Dan (Dan)" To: "Andy Bierman" , "Phil Shafer" , Subject: Re: [Netconf] Comments on draft-ietf-netconf-monitoring-06.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, 10 Aug 2009 09:17:11 -0000 =20 > -----Original Message----- > From: netconf-bounces@ietf.org=20 > [mailto:netconf-bounces@ietf.org] On Behalf Of Andy Bierman > Sent: Sunday, August 09, 2009 10:18 PM > To: Andy Bierman; Phil Shafer; netconf@ietf.org > Subject: Re: [Netconf] Comments on=20 > draft-ietf-netconf-monitoring-06.txt >=20 > Juergen Schoenwaelder wrote: > > On Sat, Aug 08, 2009 at 05:01:18PM +0200, Andy Bierman wrote: > > =20 > >> But /ietf will get huge over time. So each WG should=20 > decide its own=20 > >> container names, and not be forced to use a simple formula like=20 > >> ietf-. > >> > >> /ietf-bgp/ > >> /ietf-netconf/ > >> > >> So why don't we have any sort of data organization in NETCONF, so=20 > >> other WGs can follow our good example? Why don't we start=20 > organizing=20 > >> and structuring data so we stop setting such a bad example? > >=20 > > Using is a choice but IMHO not a very good=20 > choice; WGs are=20 > > means to organize work and they not necessarily provide good and=20 > > organized and long lasting names we are looking for. > >=20 >=20 > but this is protocol name, not WG name. >=20 > > /js > >=20 >=20 Right. These names may be different, as for example in the ietf the name of the wg dealing with bgp nowadays is idr, radext takes care of radius, and netmod is in charge with yang.=20 Dan From mehmet.ersue@nsn.com Mon Aug 10 02: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 4B94C3A6D39 for ; Mon, 10 Aug 2009 02:27:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.241 X-Spam-Level: X-Spam-Status: No, score=-3.241 tagged_above=-999 required=5 tests=[AWL=-0.642, 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 DCHlyLQlHCzu for ; Mon, 10 Aug 2009 02:27:15 -0700 (PDT) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [217.115.75.234]) by core3.amsl.com (Postfix) with ESMTP id 0E9543A6DD7 for ; Mon, 10 Aug 2009 02:27:14 -0700 (PDT) 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 n7A9RG0W020550 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 10 Aug 2009 11:27:16 +0200 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 n7A9RBc3024237; Mon, 10 Aug 2009 11:27:15 +0200 Received: from DEMUEXC005.nsn-intra.net ([10.150.128.17]) by demuexc024.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Mon, 10 Aug 2009 11:27:15 +0200 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, 10 Aug 2009 11:27:14 +0200 Message-ID: In-Reply-To: <20090808062514.GB3279@elstar.local> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Netconf] CODE BEGINS wasRe:WGLC: draft-ietf-netconf-with-defaults-02 Thread-Index: AcoX8QRGk4LaPT+VSxmUdaPzFZKNKQBqy0eg References: <000701ca1784$604a89a0$0601a8c0@allison><200908072133.n77LXY4t033853@idle.juniper.net> <20090808062514.GB3279@elstar.local> From: "Ersue, Mehmet (NSN - DE/Munich)" To: "Juergen Schoenwaelder" , "Phil Shafer" X-OriginalArrivalTime: 10 Aug 2009 09:27:15.0794 (UTC) FILETIME=[BFDC0320:01CA199C] Cc: netconf@ietf.org Subject: Re: [Netconf] CODE BEGINS wasRe:WGLC: draft-ietf-netconf-with-defaults-02 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, 10 Aug 2009 09:27:19 -0000 > =3D=3D start "foo.yang" >=20 > module foo { > // ... > } >=20 > =3D=3D end "foo.yang" Having the module name in the marking text is a good idea. =20 > That said, I do not think we need to mark every little example as > code / extractable fragments. Agreed. Mehmet =20 > /js >=20 > --=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 >=20 From mbj@tail-f.com Mon Aug 10 03:27: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 225703A6E39 for ; Mon, 10 Aug 2009 03:27:01 -0700 (PDT) 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=[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 w93EGUG0nU6P for ; Mon, 10 Aug 2009 03:26:54 -0700 (PDT) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id 1763C3A6E37 for ; Mon, 10 Aug 2009 03:26:53 -0700 (PDT) Received: from localhost (138.162.241.83.in-addr.dgcsystems.net [83.241.162.138]) by mail.tail-f.com (Postfix) with ESMTPSA id 15B2D61601A; Mon, 10 Aug 2009 12:26:51 +0200 (CEST) Date: Mon, 10 Aug 2009 12:25:25 +0200 (CEST) Message-Id: <20090810.122525.98606185.mbj@tail-f.com> To: ellison@ieee.org From: Martin Bjorklund In-Reply-To: <8a0268750908051158m2658292ctaf2a14cbd0206c39@mail.gmail.com> References: <8a0268750908051158m2658292ctaf2a14cbd0206c39@mail.gmail.com> X-Mailer: Mew version 6.0.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] Question on text constraints within for NETCONF protocol level errors 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, 10 Aug 2009 10:27:01 -0000 Hi, Mark Ellison wrote: > Now, in order to be compliant wih respect to 4741/4741bis does my > NETCONF server for errors occurring at the NETCONF protocol level need > to constrain eror-message text to that contained in Appendix A? No. In Appendix A the string is labeled "Description", and it is not intended to be used as the error-message content. This should be made more clear in 4741bis. Also note that you are free to add an error-app-tag or any error-info content to provide more specific details about the error. I have added this as issue 16 on the open issues list. /martin From mbj@tail-f.com Mon Aug 10 03:40:00 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 722593A6E45 for ; Mon, 10 Aug 2009 03:40:00 -0700 (PDT) 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=[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 qBa1FOvGZ5yY for ; Mon, 10 Aug 2009 03:39:59 -0700 (PDT) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id A33673A6A3C for ; Mon, 10 Aug 2009 03:39:59 -0700 (PDT) Received: from localhost (138.162.241.83.in-addr.dgcsystems.net [83.241.162.138]) by mail.tail-f.com (Postfix) with ESMTPSA id 0785E616007; Mon, 10 Aug 2009 12:40:03 +0200 (CEST) Date: Mon, 10 Aug 2009 12:40:02 +0200 (CEST) Message-Id: <20090810.124002.251198303.mbj@tail-f.com> To: j.schoenwaelder@jacobs-university.de From: Martin Bjorklund In-Reply-To: <20090807145009.GD2668@elstar.local> References: <20090807142152.GA2668@elstar.local> <200908071414.n77EE1ha029875@idle.juniper.net> <20090807145009.GD2668@elstar.local> X-Mailer: Mew version 6.0.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] [Fwd: New Version Notificationfor draft-ietf-netconf-with-defaults-03] 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, 10 Aug 2009 10:40:00 -0000 Juergen Schoenwaelder wrote: > On Fri, Aug 07, 2009 at 04:14:00PM +0200, Phil Shafer wrote: > > Juergen Schoenwaelder writes: > > >I also prefer to move to normative YANG in both documents. > > > > I suggested this also for the monitoring draft, and still do. > > If YANG is the future, we shouldn't be afraid of depending on > > it, even if it means a small delay. > > I am also in favour of that - and this would solve the IP address > issue. ;-) +1 /martin From mbj@tail-f.com Mon Aug 10 05:44: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 A56133A6BEA for ; Mon, 10 Aug 2009 05:44:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.94 X-Spam-Level: X-Spam-Status: No, score=-1.94 tagged_above=-999 required=5 tests=[AWL=0.106, 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 8tvmwjrG094c for ; Mon, 10 Aug 2009 05:44:11 -0700 (PDT) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id 3E30A3A6BB0 for ; Mon, 10 Aug 2009 05:43:39 -0700 (PDT) Received: from localhost (138.162.241.83.in-addr.dgcsystems.net [83.241.162.138]) by mail.tail-f.com (Postfix) with ESMTPSA id A85BB616007; Mon, 10 Aug 2009 14:43:42 +0200 (CEST) Date: Mon, 10 Aug 2009 14:43:42 +0200 (CEST) Message-Id: <20090810.144342.123608842.mbj@tail-f.com> To: andy@netconfcentral.com From: Martin Bjorklund In-Reply-To: <4A7EE8C6.5080706@netconfcentral.com> References: <4A7EE8C6.5080706@netconfcentral.com> X-Mailer: Mew version 6.0.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] validate-1.1 capability 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, 10 Aug 2009 12:44:11 -0000 Hi, Andy Bierman wrote: > Hi, > > The validate-1.1 capability is somewhat broken. [...] > So I don't want to fix it with a band-aid like this validate-1.1 > capability. validate-1.1 adds one optional enumeration value. It does not try to fix the problem you raise at all, so I don't see how it is a band-aid for this problem. > I would prefer to see all the validate capability > be mandatory (including rollback-on-error), but this > would mean a new protocol version. +1, but I'm not sure that this is important enough (on its own) to warrant a new protocol version. /martin From mbj@tail-f.com Mon Aug 10 06:18:10 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 93E093A6E61 for ; Mon, 10 Aug 2009 06:18:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.953 X-Spam-Level: X-Spam-Status: No, score=-1.953 tagged_above=-999 required=5 tests=[AWL=0.093, 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 SZ5jIympCqzx for ; Mon, 10 Aug 2009 06:18:10 -0700 (PDT) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id CB9113A6E69 for ; Mon, 10 Aug 2009 06:18:09 -0700 (PDT) Received: from localhost (138.162.241.83.in-addr.dgcsystems.net [83.241.162.138]) by mail.tail-f.com (Postfix) with ESMTPSA id 91B35616007; Mon, 10 Aug 2009 15:18:12 +0200 (CEST) Date: Mon, 10 Aug 2009 15:18:12 +0200 (CEST) Message-Id: <20090810.151812.267824031.mbj@tail-f.com> To: phil@juniper.net From: Martin Bjorklund In-Reply-To: <200908081440.n78EeQGu046784@idle.juniper.net> References: <4A7473F3.5080709@netconfcentral.com> <200908081440.n78EeQGu046784@idle.juniper.net> X-Mailer: Mew version 6.0.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] partial locking for candidate and startup? 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, 10 Aug 2009 13:18:10 -0000 Hi, Phil Shafer wrote: > Andy Bierman writes: > >Are there any plans to extend the partial locking > >feature to the candidate and startup databases? > > The opposite. I've asked that explicit language > be added to the partial lock draft saying that > it is not compatible with :candidate, since partial > locking with full commits is a non-starter. For the candidate, it has been said before that partial-locking does no more harm to the full commit model of the candidate than a candidate with no locks what so ever (which is supported by 4741). For startup, I think it makes sense to remove partial-lock, since we have clarified in 4741bis that startup cannot be modified with edit-config. /martin From phil@juniper.net Mon Aug 10 06:35: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 297993A6A1C for ; Mon, 10 Aug 2009 06:35:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.536 X-Spam-Level: X-Spam-Status: No, score=-6.536 tagged_above=-999 required=5 tests=[AWL=0.063, 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 Y2GkhK7xJfHD for ; Mon, 10 Aug 2009 06:35:15 -0700 (PDT) Received: from exprod7og120.obsmtp.com (exprod7og120.obsmtp.com [64.18.2.18]) by core3.amsl.com (Postfix) with ESMTP id 2FB2E3A6C1E for ; Mon, 10 Aug 2009 06:35:15 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob120.postini.com ([64.18.6.12]) with SMTP ID DSNKSoAiFuJ8HarKqdF6m+Na5VqPIdsvFkT+@postini.com; Mon, 10 Aug 2009 06:35:19 PDT 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, 10 Aug 2009 06:33:42 -0700 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, 10 Aug 2009 06:33:42 -0700 Received: from emailsmtp55.jnpr.net ([172.24.18.132]) by p-emlb01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Mon, 10 Aug 2009 06:33:41 -0700 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp55.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Mon, 10 Aug 2009 06:33:41 -0700 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 n7ADXed42468; Mon, 10 Aug 2009 06:33:40 -0700 (PDT) (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 n7ADLxqS058788; Mon, 10 Aug 2009 13:21:59 GMT (envelope-from phil@idle.juniper.net) Message-ID: <200908101321.n7ADLxqS058788@idle.juniper.net> To: Andy Bierman In-Reply-To: <4A7F20EB.2010002@netconfcentral.com> Date: Mon, 10 Aug 2009 09:21:59 -0400 From: Phil Shafer X-OriginalArrivalTime: 10 Aug 2009 13:33:41.0007 (UTC) FILETIME=[2C8879F0:01CA19BF] MIME-Version: 1.0 Content-Type: text/plain Cc: "netconf@ietf.org" Subject: Re: [Netconf] Comments on draft-ietf-netconf-monitoring-06.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, 10 Aug 2009 13:35:16 -0000 Andy Bierman writes: >but this is protocol name, not WG name. There should be an organization above the protocol name containing the area on which the protocol works. At a minimum, this could be the ietf area, but something better (perhaps determined by the area directors for that area?) should be easily possible. A strawman: /ietf + /protocols + /management + /snmp + /netconf + /routing + /bgp + /ospf + /layer-2 + /spanning-tree + /mpls + /path-management + /rvsp + /ldp + /security + /ipsec + /eap + /ipr + /lawyer-fodder Or: /ietf + /area + /applications + /general + /internet + /oam + /netconf + /snmp + /real-time + /routing + /mpls + /rsvp + /ldp + /bgp + /security + /transport + /other Or perhaps put bgp under "egp" and "ospf" and "isis" under "igp". Thanks, Phil From phil@juniper.net Mon Aug 10 06:49: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 CF5873A68DF for ; Mon, 10 Aug 2009 06:49:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.542 X-Spam-Level: X-Spam-Status: No, score=-6.542 tagged_above=-999 required=5 tests=[AWL=0.057, 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 VHVdyHD0jkji for ; Mon, 10 Aug 2009 06:49:19 -0700 (PDT) Received: from exprod7og116.obsmtp.com (exprod7og116.obsmtp.com [64.18.2.219]) by core3.amsl.com (Postfix) with ESMTP id C40283A6E7C for ; Mon, 10 Aug 2009 06:49:15 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob116.postini.com ([64.18.6.12]) with SMTP ID DSNKSoAlXGBwzUn8xEY4CV0oR+npQ0M0bMhV@postini.com; Mon, 10 Aug 2009 06:49:19 PDT 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, 10 Aug 2009 06:47:54 -0700 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, 10 Aug 2009 06:47:54 -0700 Received: from emailsmtp55.jnpr.net ([172.24.18.132]) by p-emlb02-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Mon, 10 Aug 2009 06:47:53 -0700 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp55.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Mon, 10 Aug 2009 06:47:53 -0700 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 n7ADlqd47669; Mon, 10 Aug 2009 06:47:52 -0700 (PDT) (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 n7ADaAh7058925; Mon, 10 Aug 2009 13:36:11 GMT (envelope-from phil@idle.juniper.net) Message-ID: <200908101336.n7ADaAh7058925@idle.juniper.net> To: Tomasz Mikolajczyk In-Reply-To: <4A7FCA1E.70105@s3group.com> Date: Mon, 10 Aug 2009 09:36:10 -0400 From: Phil Shafer X-OriginalArrivalTime: 10 Aug 2009 13:47:53.0314 (UTC) FILETIME=[288C3420:01CA19C1] MIME-Version: 1.0 Content-Type: text/plain Cc: Netconf Subject: Re: [Netconf] Fw: Database Architecture OK or NOT-OK? 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, 10 Aug 2009 13:49:19 -0000 Tomasz Mikolajczyk writes: >I don't agree. That's not guarantee atomicity! What if a management >system losses a connection with a managed device in the middle of >commit? Regardless of the connection, the commit operation on the device must be atomic, either succeeding or failing completely. A failed connection should not leave the device with a 1/2 committed config. >Management system (NETCONF agent) cannot guarantee atomicity on >its own. "Management system" != "NETCONF agent", right? Oh, you mean the on-the-box mgmt software? Either way: >Device must support atomic operations and transactions. Absolutely. Thanks, Phil From mbj@tail-f.com Mon Aug 10 06:50:42 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 C09EB28C107 for ; Mon, 10 Aug 2009 06:50:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.963 X-Spam-Level: X-Spam-Status: No, score=-1.963 tagged_above=-999 required=5 tests=[AWL=0.083, 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 sOovaeDS-sqF for ; Mon, 10 Aug 2009 06:50:42 -0700 (PDT) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id C359128C0ED for ; Mon, 10 Aug 2009 06:50:41 -0700 (PDT) Received: from localhost (138.162.241.83.in-addr.dgcsystems.net [83.241.162.138]) by mail.tail-f.com (Postfix) with ESMTPSA id 69C4F616007; Mon, 10 Aug 2009 15:50:44 +0200 (CEST) Date: Mon, 10 Aug 2009 15:50:44 +0200 (CEST) Message-Id: <20090810.155044.212671920.mbj@tail-f.com> To: phil@juniper.net From: Martin Bjorklund In-Reply-To: <200908101321.n7ADLxqS058788@idle.juniper.net> References: <4A7F20EB.2010002@netconfcentral.com> <200908101321.n7ADLxqS058788@idle.juniper.net> X-Mailer: Mew version 6.0.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] Comments on draft-ietf-netconf-monitoring-06.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, 10 Aug 2009 13:50:42 -0000 Phil Shafer wrote: > Andy Bierman writes: > >but this is protocol name, not WG name. > > There should be an organization above the protocol name containing > the area on which the protocol works. At a minimum, this could be > the ietf area, but something better (perhaps determined by the > area directors for that area?) should be easily possible. > > A strawman: > > /ietf > + /protocols > + /management > + /snmp > + /netconf > + /routing > + /bgp > + /ospf > + /layer-2 > + /spanning-tree > + /mpls > + /path-management > + /rvsp > + /ldp > + /security > + /ipsec > + /eap > + /ipr > + /lawyer-fodder I am concerned that this approach is over-designed. This means that this hierarchy must be defined in one or more YANG modules, defining one or more XML namespaces. Every other module must augment this (or of these) module(s). module ietf-general { namespace "urn:ietf:params:general"; prefix ietf; container ietf; } module ietf-protocols { namespace "urn:ietf:params:protocols"; prefix proto; import ietf-general { prefix ietf; } augment "/ietf:ietf" { container protocols; } } ... module ietf-netconf-state { namespace "urn:ietf:params:xml:ns:netconf:state"; prefix ns; // a couple of imports here... augment "/ietf:ietf/proto:protocols/mgmt:management" { container netconf { ... } } } And then the XML will have to get the namespaces right: ... ... ... If the complete structure (down to individual protocols etc) is defined in one ietf-hierarchy module, which is "often" updated as needed, things would be a bit simpler. /martin From phil@juniper.net Mon Aug 10 06:55:59 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 F03513A6CF2 for ; Mon, 10 Aug 2009 06:55:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.543 X-Spam-Level: X-Spam-Status: No, score=-6.543 tagged_above=-999 required=5 tests=[AWL=0.056, 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 v5q0FgmazF5s for ; Mon, 10 Aug 2009 06:55:59 -0700 (PDT) Received: from exprod7og120.obsmtp.com (exprod7og120.obsmtp.com [64.18.2.18]) by core3.amsl.com (Postfix) with ESMTP id 5D9CE3A6AA4 for ; Mon, 10 Aug 2009 06:55:58 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob120.postini.com ([64.18.6.12]) with SMTP ID DSNKSoAm7+8jmY/R9o0CZjCp8kK3QMFaVyim@postini.com; Mon, 10 Aug 2009 06:56:03 PDT 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, 10 Aug 2009 06:53:26 -0700 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, 10 Aug 2009 06:53:26 -0700 Received: from emailsmtp55.jnpr.net ([172.24.18.132]) by p-emlb02-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Mon, 10 Aug 2009 06:53:26 -0700 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp55.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Mon, 10 Aug 2009 06:53:25 -0700 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 n7ADrPd50252; Mon, 10 Aug 2009 06:53:25 -0700 (PDT) (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 n7ADfh7R059002; Mon, 10 Aug 2009 13:41:44 GMT (envelope-from phil@idle.juniper.net) Message-ID: <200908101341.n7ADfh7R059002@idle.juniper.net> To: Martin Bjorklund In-Reply-To: <20090810.151812.267824031.mbj@tail-f.com> Date: Mon, 10 Aug 2009 09:41:43 -0400 From: Phil Shafer X-OriginalArrivalTime: 10 Aug 2009 13:53:25.0843 (UTC) FILETIME=[EEC01A30:01CA19C1] MIME-Version: 1.0 Content-Type: text/plain Cc: netconf@ietf.org Subject: Re: [Netconf] partial locking for candidate and startup? 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, 10 Aug 2009 13:56:00 -0000 Martin Bjorklund writes: >For the candidate, it has been said before that partial-locking does >no more harm to the full commit model of the candidate than a >candidate with no locks what so ever (which is supported by 4741). For :writable-running, partial locking completely interfers with the standard global locking, preventing even the most mundane "archive the configuration" application from completing successfully. For candidate, the entire purpose is to provide a simple transaction mechanism. Partial locks block the normal function of that mechanism, preventing the use of locks, and putting us back in the "well I hope I didn't just break the entire network" world. Thanks, Phil From phil@juniper.net Mon Aug 10 07:15: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 DA8AF3A67B4 for ; Mon, 10 Aug 2009 07:15:15 -0700 (PDT) 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 wrzYV-erIukO for ; Mon, 10 Aug 2009 07:15:15 -0700 (PDT) Received: from exprod7og126.obsmtp.com (exprod7og126.obsmtp.com [64.18.2.206]) by core3.amsl.com (Postfix) with ESMTP id 3740828C0FD for ; Mon, 10 Aug 2009 07:15:14 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob126.postini.com ([64.18.6.12]) with SMTP ID DSNKSoArc94t9VkTzdXZ0meQh8e3UrydMdX9@postini.com; Mon, 10 Aug 2009 07:15:19 PDT 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, 10 Aug 2009 07:11:55 -0700 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, 10 Aug 2009 07:11:56 -0700 Received: from emailsmtp55.jnpr.net ([172.24.18.132]) by p-emlb01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Mon, 10 Aug 2009 07:11:56 -0700 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp55.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Mon, 10 Aug 2009 07:11:55 -0700 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 n7AEBsd59135; Mon, 10 Aug 2009 07:11:54 -0700 (PDT) (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 n7AE0DCx059174; Mon, 10 Aug 2009 14:00:13 GMT (envelope-from phil@idle.juniper.net) Message-ID: <200908101400.n7AE0DCx059174@idle.juniper.net> To: Juergen Schoenwaelder In-Reply-To: <20090809205432.GA4430@elstar.local> Date: Mon, 10 Aug 2009 10:00:12 -0400 From: Phil Shafer X-OriginalArrivalTime: 10 Aug 2009 14:11:55.0102 (UTC) FILETIME=[83EB97E0:01CA19C4] MIME-Version: 1.0 Content-Type: text/plain Cc: Netconf Subject: Re: [Netconf] Fw: Database Architecture OK or NOT-OK? 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, 10 Aug 2009 14:15:15 -0000 Juergen Schoenwaelder writes: >Do you blow away changes that were made to running? I don't support :writable-running, just :candidate, and the interaction between the two isn't clear. Martin, how does this work on your sw? >Since candidate is a shared buffer, how can I every >use discard-changes() in a save way without having a proper lock? If there are outstanding changes, the software client cannot make any serious assumption about their nature, so choosing to blow them away is something best left to a human. >You seem to want to protect applications that do not use locks >properly and I wonder how this is ever going to work. I don't see it this way. I want to protect applications that are using locks in a responsible manner from dangerous interactions with other sources of configuration that are not behaving well. >In other words, a session that causes >candidate to be dirty (and see above that it is not clear what dirty >means with :writable-running) and goes away will cause all other well >written applications to stop working. Exactly. An client (human or sw) that leaves (or keeps) the box in an undefined state is not a suitation that a non-ai piece of software can reasonable resolve. Send an alarm and let something smarter resolve it. >Concrete question to you: Does the Junos CLI use locks or only when >specifically asked to use locks? The candidate config in JUNOS is shared between all CLI users, and locks are not mandatory. The "configure" command enters configuration mode, and the "configure exclusive" command grabs the lock before entering configuration mode. These same "dirty" rules apply. For three people working together to solve a, say, bgp policy problem, using the shared workspace works well. But in the interaction between humans and applications means, the human should always win. Hmmmm, the three laws of management applications: (1) An automation may not break human configuration or, through action or inaction, allow human configuration to be broken. (2) An automation must try to get it's job done, except where such attempts would conflict with the First Law. (3) An automation must protect its own existence, by applying the First and Second Laws in a way that does not tempt the human to turn it off. I, Config? Thanks, Phil From phil@juniper.net Mon Aug 10 07:27:00 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 B1BDC28C124 for ; Mon, 10 Aug 2009 07:27:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.545 X-Spam-Level: X-Spam-Status: No, score=-6.545 tagged_above=-999 required=5 tests=[AWL=0.054, 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 vSrHogecQN0X for ; Mon, 10 Aug 2009 07:26:59 -0700 (PDT) Received: from exprod7og120.obsmtp.com (exprod7og120.obsmtp.com [64.18.2.18]) by core3.amsl.com (Postfix) with ESMTP id 220783A68AF for ; Mon, 10 Aug 2009 07:26:59 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob120.postini.com ([64.18.6.12]) with SMTP ID DSNKSoAuNrjCd1P2IR7pUeYsT2jT0AADObvh@postini.com; Mon, 10 Aug 2009 07:27:03 PDT 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, 10 Aug 2009 07:23:24 -0700 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, 10 Aug 2009 07:23:24 -0700 Received: from emailsmtp55.jnpr.net ([172.24.18.132]) by p-emlb02-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Mon, 10 Aug 2009 07:23:23 -0700 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp55.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Mon, 10 Aug 2009 07:23:23 -0700 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 n7AENMd63839; Mon, 10 Aug 2009 07:23:22 -0700 (PDT) (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 n7AEBf1Y059323; Mon, 10 Aug 2009 14:11:41 GMT (envelope-from phil@idle.juniper.net) Message-ID: <200908101411.n7AEBf1Y059323@idle.juniper.net> To: Andy Bierman In-Reply-To: <4A7EE8C6.5080706@netconfcentral.com> Date: Mon, 10 Aug 2009 10:11:41 -0400 From: Phil Shafer X-OriginalArrivalTime: 10 Aug 2009 14:23:23.0316 (UTC) FILETIME=[1E20B740:01CA19C6] MIME-Version: 1.0 Content-Type: text/plain Cc: NETCONF Subject: Re: [Netconf] validate-1.1 capability 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, 10 Aug 2009 14:27:00 -0000 Andy Bierman writes: >The validate-1.1 capability is somewhat broken. >I would prefer to see all the validate capability >be mandatory (including rollback-on-error), but this >would mean a new protocol version. "Doesn't work the way I prefer" != "broken", right? >It is trivial to implement test-only, but it is >only available if the agent implements test-then-set >and the operation. In some implementations, test-only requires a complete copy of the configuration, which for some devices was seen as an impediment to their adoption of netconf. So it's optional. >As Balazs pointed out many times already, the fact that >the manager MUST NOT provide this parameter unless >:validate is supported is really fragile. If your kernel doesn't support TIOCGWINSZ, calling ioctl with that parameter will get you an error. Does that make your kernel "really fragile"? NETCONF isn't supposed to force the device to live by a single set of rules (not that the nm community could ever agree on that set of rules), but to allow the device to let you know what you can and cannot do to it. Once it has told you, it's the client responsibility to act accordingly. >I want to change 4741bis to reflect this behavior, -1: This would be a break in backwards compatibility. >By insisting that the protocol version stay the >same, the WG is actually making NETCONF harder to >use for NMS developers, not easier. NMS developers that want "set" can say "set". This may be slightly less convenient for them, but I don't see this as a serious hardship. Thanks, Phil From mehmet.ersue@nsn.com Mon Aug 10 07:27: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 469DA28C14E for ; Mon, 10 Aug 2009 07:27:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.91 X-Spam-Level: X-Spam-Status: No, score=-4.91 tagged_above=-999 required=5 tests=[AWL=1.089, BAYES_00=-2.599, J_CHICKENPOX_35=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 gmfcYXsSkJ+w for ; Mon, 10 Aug 2009 07:27:12 -0700 (PDT) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [217.115.75.233]) by core3.amsl.com (Postfix) with ESMTP id B02353A68AF for ; Mon, 10 Aug 2009 07:27:11 -0700 (PDT) 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 n7AERCi2004371 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 10 Aug 2009 16:27:12 +0200 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 n7AERCaM031806; Mon, 10 Aug 2009 16:27:12 +0200 Received: from DEMUEXC005.nsn-intra.net ([10.150.128.17]) by demuexc022.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Mon, 10 Aug 2009 16:27:11 +0200 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, 10 Aug 2009 16:27:10 +0200 Message-ID: In-Reply-To: <000701ca1784$604a89a0$0601a8c0@allison> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: CODE BEGINS wasRe: [Netconf] WGLC: draft-ietf-netconf-with-defaults-02 Thread-Index: AcoXjN5K4kqLIjzISo6wgT1LZ/s/8QCOOo2g References: <000701ca1784$604a89a0$0601a8c0@allison> From: "Ersue, Mehmet (NSN - DE/Munich)" To: "tom.petch" , X-OriginalArrivalTime: 10 Aug 2009 14:27:11.0912 (UTC) FILETIME=[A661B280:01CA19C6] Subject: Re: [Netconf] CODE BEGINS wasRe: WGLC: draft-ietf-netconf-with-defaults-02 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, 10 Aug 2009 14:27:13 -0000 I agree that it is not necessary to label every small example code as "CODE". But it is up to the contributor of the code to decide whether he or she sees it as worth to license. Cheers, Mehmet =20 > -----Original Message----- > From: ext tom.petch [mailto:cfinss@dial.pipex.com]=20 > Sent: Friday, August 07, 2009 7:24 PM > To: Ersue, Mehmet (NSN - DE/Munich); netconf@ietf.org > Subject: CODE BEGINS wasRe: [Netconf] WGLC:=20 > draft-ietf-netconf-with-defaults-02 >=20 > Mehmet >=20 > I am not sure that I agree with you suggestion to wrap the=20 > example XML in this > I-D with CODE BEGINS and CODE ENDS. It is not clear to me=20 > that this achieves > what is intended. >=20 > Code has become a technical, legal term, defining those parts=20 > of an I-D that can > be extracted and modified without further permission outside=20 > the IETF standards > process, as opposed to requiring special permission from the=20 > IETF Trust so to > do. >=20 > As RFC5377 s4.3 says, > "Additionally, the Trustees of the IETF Trust should define=20 > a textual > representation to be included in an IETF Contribution to indicate > that a portion of the document is considered by the authors (and > later, the working group, and upon approval, the IETF) to=20 > be code and > thus subject to the permissions granted to use code." >=20 > So I see this is nothing to do with an agreement in the IESG;=20 > it is a matter for > Balazs and Andy, and perhaps the rest of the Working Group,=20 > whether or not they > wish to make such a grant. >=20 > While I see it as appropriate to grant such permission for=20 > Appendix A and > Section 4, indeed it would by default be so, for myself, I=20 > would not grant it > for informal snippets that may or may not have been validated=20 > and tested. So > for me, wrapping up everything that is code-like so as to=20 > grant that extra > copyright would be wrong. But as I say, it is in the first=20 > place up to Balazs > and Andy. >=20 > Tom Petch >=20 > ----- Original Message ----- > From: "Ersue, Mehmet (NSN - DE/Munich)" > To: > Sent: Thursday, August 06, 2009 5:55 PM > Subject: Re: [Netconf] WGLC: draft-ietf-netconf-with-defaults-02 >=20 >=20 >=20 > Hi, >=20 > I reviewed the I-D draft-ietf-netconf-with-defaults-03.txt > for WGLC. Please find my comments below. >=20 > Abstract > - s/manger/manager/ >=20 > Ch. 1. Introduction > - Last paragraph: > I agree their is no explicite statement on default/non-default > handling in RFC 4741. > OTOH RFC 4741 says that in case a filter element is not > defined the "entire configuration" is returned for a > operation. > As a native reader of the standard I interprete this as > the default behaviour of NETCONF protocol, where both, > default and non-default data, are returned. >=20 > But the With-default draft assumes the opposite, i.e. the > default behaviour of the NETCONF protocol is to suppress > the default data in message. >=20 > I think we need to align the two documents by choosing > one of the options: > a) add a clear statement to 4741bis saying that > "the agent MAY suppress the default data" or > b) address the assumption of a native 4741 reader > in With-defaults draft I mentioned above. >=20 > Ch. 1.1.2. NETCONF Terms >=20 > I agree that if the default is '3' and the value is '3', it is > considered to contain the default, regardless of how it > was created. >=20 > The draft does not specify explicitly set (default) data > clearly. > How do we handle non-default values which have been > set explicitely, where the default is '3' but the value is > _not_ '3' ? Are they suppressed too? >=20 >=20 > Ch. 1.2. Current handling of default data >=20 > - Change: > o explicit: Report values if they are explicitly set. > For state data this has the same effect as report-all > to > o explicit: Report values if they are explicitly set and > match the default. For state data this has the same > effect as report-all >=20 > - s/report-all/report-all./ >=20 >=20 > Ch. 2.5. Modifications to Existing Operations >=20 > - Enclose the example code in and > as a preparation for the code licence > statement. >=20 > Ch. 4. Data Model XSD >=20 > - I checked the XSD model for it's validity. The XSD > model is valid. >=20 > - Unfortunately we have still the policy in O&M area to > use XSD as the normative language for data models. > If we want to publish the With-defaults draft soon I > would suggest to follow the example of Partial Lock > draft and indicate the XSD as normative. > To keep them together I would put the XSD schema > and YANG module into the appendix. >=20 > OTOH if the authors and the WG decide that the > With-default draft should be published together > with 4747bis and after the publication of YANG > we can mark the YAM as normative. In this case > there is no need for XSD at all. >=20 > Change log - 01-02: > says "Placeholder for YAM added, XSD will be > removed when 4741 provides the NETCONF YAM." >=20 > We cannot remove the XSD if this draft gets > published before YANG becomes normative. >=20 > Cheers, > Mehmet >=20 > From: netconf-bounces@ietf.org [mailto:netconf-bounces@ietf.org] On > Behalf Of ext Ersue, Mehmet (NSN - DE/Munich) > Sent: Monday, August 03, 2009 11:42 PM > To: netconf@ietf.org > Subject: [Netconf] WGLC: draft-ietf-netconf-with-defaults-02 >=20 > Dear NETCONF WG, > we had a good progress on the draft "With-defaults capability > for NETCONF". In the NETCONF session at IETF we decided to > bring the draft to WGLC to initiate additional discussion. > With this mail we start a WGLC for the "With-defaults capability > for NETCONF" draft, which is planned to publish as a Proposed > Standard RFC. The WGLC will run until August 21, 2009. > Everybody on the NETCONF WG maillist PLEASE REVIEW the > draft and send your comments to the NETCONF maillist. > (http://tools.ietf.org/html/draft-ietf-netconf-with-defaults-02) > Thank you and looking forward for your comments. > Cheers, > Mehmet >=20 >=20 >=20 >=20 >=20 > -------------------------------------------------------------- > ------------------ >=20 >=20 > > _______________________________________________ > > Netconf mailing list > > Netconf@ietf.org > > https://www.ietf.org/mailman/listinfo/netconf > > >=20 >=20 From phil@juniper.net Mon Aug 10 07:29: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 DFC243A6E7B for ; Mon, 10 Aug 2009 07:29:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.546 X-Spam-Level: X-Spam-Status: No, score=-6.546 tagged_above=-999 required=5 tests=[AWL=0.053, 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 BrCqY18HC520 for ; Mon, 10 Aug 2009 07:29:27 -0700 (PDT) Received: from exprod7og122.obsmtp.com (exprod7og122.obsmtp.com [64.18.2.22]) by core3.amsl.com (Postfix) with ESMTP id B34C93A67A6 for ; Mon, 10 Aug 2009 07:29:24 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob122.postini.com ([64.18.6.12]) with SMTP ID DSNKSoAuxt0sIE76yWRHlALLMCfeFAadkbJm@postini.com; Mon, 10 Aug 2009 07:29:29 PDT 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, 10 Aug 2009 07:25:38 -0700 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, 10 Aug 2009 07:25:39 -0700 Received: from emailsmtp55.jnpr.net ([172.24.18.132]) by p-emlb01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Mon, 10 Aug 2009 07:25:38 -0700 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp55.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Mon, 10 Aug 2009 07:25:37 -0700 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 n7AEPbd65202; Mon, 10 Aug 2009 07:25:37 -0700 (PDT) (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 n7AEDtQE059367; Mon, 10 Aug 2009 14:13:55 GMT (envelope-from phil@idle.juniper.net) Message-ID: <200908101413.n7AEDtQE059367@idle.juniper.net> To: Martin Bjorklund In-Reply-To: <20090810.155044.212671920.mbj@tail-f.com> Date: Mon, 10 Aug 2009 10:13:55 -0400 From: Phil Shafer X-OriginalArrivalTime: 10 Aug 2009 14:25:37.0800 (UTC) FILETIME=[6E495880:01CA19C6] MIME-Version: 1.0 Content-Type: text/plain Cc: netconf@ietf.org Subject: Re: [Netconf] Comments on draft-ietf-netconf-monitoring-06.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, 10 Aug 2009 14:29:28 -0000 Martin Bjorklund writes: >This means that this hierarchy must be defined in one or more YANG >modules, defining one or more XML namespaces. Every other module must >augment this (or of these) module(s). I'm advocating an organizational hierarchy, not a ton of modules. I've no issue with this being in one "ietf.yang" module. Thanks, Phil From jmh@joelhalpern.com Mon Aug 10 07:51:35 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 9BB1E3A6C8E for ; Mon, 10 Aug 2009 07:51:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.137 X-Spam-Level: X-Spam-Status: No, score=-3.137 tagged_above=-999 required=5 tests=[AWL=-0.138, BAYES_00=-2.599, J_CHICKENPOX_35=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6gE08EzG1Fnk for ; Mon, 10 Aug 2009 07:51:34 -0700 (PDT) Received: from hermes.mail.tigertech.net (hermes.mail.tigertech.net [64.62.209.72]) by core3.amsl.com (Postfix) with ESMTP id 864903A6A73 for ; Mon, 10 Aug 2009 07:51:34 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 852324302E4; Mon, 10 Aug 2009 07:51:38 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hermes.tigertech.net Received: from [10.10.10.101] (pool-71-161-51-13.clppva.btas.verizon.net [71.161.51.13]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by hermes.tigertech.net (Postfix) with ESMTP id 52CEE4302DE; Mon, 10 Aug 2009 07:51:37 -0700 (PDT) Message-ID: <4A8033F8.6060501@joelhalpern.com> Date: Mon, 10 Aug 2009 10:51:36 -0400 From: "Joel M. Halpern" User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) MIME-Version: 1.0 To: "Ersue, Mehmet (NSN - DE/Munich)" References: <000701ca1784$604a89a0$0601a8c0@allison> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: netconf@ietf.org Subject: Re: [Netconf] CODE BEGINS wasRe: WGLC: draft-ietf-netconf-with-defaults-02 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, 10 Aug 2009 14:51:35 -0000 We seem to be mixing two very different kinds of marking in this discussion. One use of marking is to make it easier for a tool to extract the marked material. Given taht folks using other languages have not had any problem with this, I am not sure what the need is. (I had to extract XML Schema and XML content from an I-D for validation. Reviewers had to extract it. Another participant had to extract it. The extraction was not a problem.) However, if you really want to mark that, it is the WG's priviledge. Please do not confuse that with the granting of rights for folks to use the code. As defined by the IETF trust, folks can use the YANG code from our documents any way they want to. No marking is needed. If there is other material that is not YANG, not XML Schema, and not ABNF, that folks need to be able to extract, modify, and use, please use the trust defined labels to mark that material. Yours, Joel Ersue, Mehmet (NSN - DE/Munich) wrote: > I agree that it is not necessary to label every small example code as > "CODE". > But it is up to the contributor of the code to decide whether he or she > sees it as worth to license. > > Cheers, > Mehmet > > >> -----Original Message----- >> From: ext tom.petch [mailto:cfinss@dial.pipex.com] >> Sent: Friday, August 07, 2009 7:24 PM >> To: Ersue, Mehmet (NSN - DE/Munich); netconf@ietf.org >> Subject: CODE BEGINS wasRe: [Netconf] WGLC: >> draft-ietf-netconf-with-defaults-02 >> >> Mehmet >> >> I am not sure that I agree with you suggestion to wrap the >> example XML in this >> I-D with CODE BEGINS and CODE ENDS. It is not clear to me >> that this achieves >> what is intended. >> >> Code has become a technical, legal term, defining those parts >> of an I-D that can >> be extracted and modified without further permission outside >> the IETF standards >> process, as opposed to requiring special permission from the >> IETF Trust so to >> do. >> >> As RFC5377 s4.3 says, >> "Additionally, the Trustees of the IETF Trust should define >> a textual >> representation to be included in an IETF Contribution to indicate >> that a portion of the document is considered by the authors (and >> later, the working group, and upon approval, the IETF) to >> be code and >> thus subject to the permissions granted to use code." >> >> So I see this is nothing to do with an agreement in the IESG; >> it is a matter for >> Balazs and Andy, and perhaps the rest of the Working Group, >> whether or not they >> wish to make such a grant. >> >> While I see it as appropriate to grant such permission for >> Appendix A and >> Section 4, indeed it would by default be so, for myself, I >> would not grant it >> for informal snippets that may or may not have been validated >> and tested. So >> for me, wrapping up everything that is code-like so as to >> grant that extra >> copyright would be wrong. But as I say, it is in the first >> place up to Balazs >> and Andy. >> >> Tom Petch >> >> ----- Original Message ----- >> From: "Ersue, Mehmet (NSN - DE/Munich)" >> To: >> Sent: Thursday, August 06, 2009 5:55 PM >> Subject: Re: [Netconf] WGLC: draft-ietf-netconf-with-defaults-02 >> >> >> >> Hi, >> >> I reviewed the I-D draft-ietf-netconf-with-defaults-03.txt >> for WGLC. Please find my comments below. >> >> Abstract >> - s/manger/manager/ >> >> Ch. 1. Introduction >> - Last paragraph: >> I agree their is no explicite statement on default/non-default >> handling in RFC 4741. >> OTOH RFC 4741 says that in case a filter element is not >> defined the "entire configuration" is returned for a >> operation. >> As a native reader of the standard I interprete this as >> the default behaviour of NETCONF protocol, where both, >> default and non-default data, are returned. >> >> But the With-default draft assumes the opposite, i.e. the >> default behaviour of the NETCONF protocol is to suppress >> the default data in message. >> >> I think we need to align the two documents by choosing >> one of the options: >> a) add a clear statement to 4741bis saying that >> "the agent MAY suppress the default data" or >> b) address the assumption of a native 4741 reader >> in With-defaults draft I mentioned above. >> >> Ch. 1.1.2. NETCONF Terms >> >> I agree that if the default is '3' and the value is '3', it is >> considered to contain the default, regardless of how it >> was created. >> >> The draft does not specify explicitly set (default) data >> clearly. >> How do we handle non-default values which have been >> set explicitely, where the default is '3' but the value is >> _not_ '3' ? Are they suppressed too? >> >> >> Ch. 1.2. Current handling of default data >> >> - Change: >> o explicit: Report values if they are explicitly set. >> For state data this has the same effect as report-all >> to >> o explicit: Report values if they are explicitly set and >> match the default. For state data this has the same >> effect as report-all >> >> - s/report-all/report-all./ >> >> >> Ch. 2.5. Modifications to Existing Operations >> >> - Enclose the example code in and >> as a preparation for the code licence >> statement. >> >> Ch. 4. Data Model XSD >> >> - I checked the XSD model for it's validity. The XSD >> model is valid. >> >> - Unfortunately we have still the policy in O&M area to >> use XSD as the normative language for data models. >> If we want to publish the With-defaults draft soon I >> would suggest to follow the example of Partial Lock >> draft and indicate the XSD as normative. >> To keep them together I would put the XSD schema >> and YANG module into the appendix. >> >> OTOH if the authors and the WG decide that the >> With-default draft should be published together >> with 4747bis and after the publication of YANG >> we can mark the YAM as normative. In this case >> there is no need for XSD at all. >> >> Change log - 01-02: >> says "Placeholder for YAM added, XSD will be >> removed when 4741 provides the NETCONF YAM." >> >> We cannot remove the XSD if this draft gets >> published before YANG becomes normative. >> >> Cheers, >> Mehmet >> >> From: netconf-bounces@ietf.org [mailto:netconf-bounces@ietf.org] On >> Behalf Of ext Ersue, Mehmet (NSN - DE/Munich) >> Sent: Monday, August 03, 2009 11:42 PM >> To: netconf@ietf.org >> Subject: [Netconf] WGLC: draft-ietf-netconf-with-defaults-02 >> >> Dear NETCONF WG, >> we had a good progress on the draft "With-defaults capability >> for NETCONF". In the NETCONF session at IETF we decided to >> bring the draft to WGLC to initiate additional discussion. >> With this mail we start a WGLC for the "With-defaults capability >> for NETCONF" draft, which is planned to publish as a Proposed >> Standard RFC. The WGLC will run until August 21, 2009. >> Everybody on the NETCONF WG maillist PLEASE REVIEW the >> draft and send your comments to the NETCONF maillist. >> (http://tools.ietf.org/html/draft-ietf-netconf-with-defaults-02) >> Thank you and looking forward for your comments. >> Cheers, >> Mehmet >> >> >> >> >> >> -------------------------------------------------------------- >> ------------------ >> >> >>> _______________________________________________ >>> Netconf mailing list >>> Netconf@ietf.org >>> https://www.ietf.org/mailman/listinfo/netconf >>> >> > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf > From andy@netconfcentral.com Mon Aug 10 08:06: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 1FC9F3A6E9E for ; Mon, 10 Aug 2009 08:06:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.485 X-Spam-Level: X-Spam-Status: No, score=-2.485 tagged_above=-999 required=5 tests=[AWL=0.114, 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 kv0uRp8A9YP9 for ; Mon, 10 Aug 2009 08:06:40 -0700 (PDT) Received: from smtp113.sbc.mail.mud.yahoo.com (smtp113.sbc.mail.mud.yahoo.com [68.142.198.212]) by core3.amsl.com (Postfix) with SMTP id 34D0C3A6E9F for ; Mon, 10 Aug 2009 08:06:40 -0700 (PDT) Received: (qmail 76762 invoked from network); 10 Aug 2009 15:06:41 -0000 Received: from unknown (HELO ?192.168.0.10?) (andy@67.125.157.61 with plain) by smtp113.sbc.mail.mud.yahoo.com with SMTP; 10 Aug 2009 15:06:41 -0000 X-YMail-OSG: OmzKUi8VM1mqgywYhOaZpAjJqmFpS34CiGBwzG0wUHBcO_pUA1H6LECSyPV0b2etO.zqbqAV4FNTnN7BvLySJQALfR90ScDHu5JVxK7idKW_iLfupya8IYG9va_553e9R1.wLg7oIWxfCI7SnfruHfrRij_6UCTuxKNUqiQx.flvistjUwziwVyOlhn9NY0CtSJTTmEOfNpmAkP0D_8QmLkMMrMDm_zFuftUcFuFeAQvVFycieS2k03xetifUkuqGdHq0R9rs6oxmjhgIExziJGivjF12Z6__u6.3gKwgkDChPaskgc- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4A8037CD.2060307@netconfcentral.com> Date: Mon, 10 Aug 2009 08:07:57 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.22 (X11/20090608) MIME-Version: 1.0 To: Phil Shafer References: <200908101411.n7AEBf1Y059323@idle.juniper.net> In-Reply-To: <200908101411.n7AEBf1Y059323@idle.juniper.net> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: NETCONF Subject: Re: [Netconf] validate-1.1 capability 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, 10 Aug 2009 15:06:41 -0000 Phil Shafer wrote: > Andy Bierman writes: >> The validate-1.1 capability is somewhat broken. >> I would prefer to see all the validate capability >> be mandatory (including rollback-on-error), but this >> would mean a new protocol version. > > "Doesn't work the way I prefer" != "broken", right? > It is trivial to have a leaf parameter called . There are 2 design choices the NETCONF WG keeps making that are going to be a big problem later, when all the YANG modules in the world cannot be counted on one hand. 1) over-loading existing capabilities with new requirements and meanings, so the NMS has to look at a hard-wired set of variables (not all boolean) to see how the agent really works for some operation. 2) using capabilities to micro-partition the data model. The if-feature-stmt is great because you cannot set the granularity any finer than a single leaf. There needs to be a balance between implementation requirements on the manager and the agent. >> It is trivial to implement test-only, but it is >> only available if the agent implements test-then-set >> and the operation. > > In some implementations, test-only requires a complete copy of the > configuration, which for some devices was seen as an impediment to > their adoption of netconf. So it's optional. > >> As Balazs pointed out many times already, the fact that >> the manager MUST NOT provide this parameter unless >> :validate is supported is really fragile. > > If your kernel doesn't support TIOCGWINSZ, calling ioctl with that > parameter will get you an error. Does that make your kernel > "really fragile"? > This is an API that we have control over. It is not some HW error in the kernel. That has nothing to do with how easy it is for a manager to use the API. > NETCONF isn't supposed to force the device to live by a single set > of rules (not that the nm community could ever agree on that set > of rules), but to allow the device to let you know what you can and > cannot do to it. Once it has told you, it's the client responsibility > to act accordingly. > >> I want to change 4741bis to reflect this behavior, > > -1: This would be a break in backwards compatibility. > >> By insisting that the protocol version stay the >> same, the WG is actually making NETCONF harder to >> use for NMS developers, not easier. > > NMS developers that want "set" can say "set". This may be slightly > less convenient for them, but I don't see this as a serious hardship. > > Thanks, > Phil > Andy From andy@netconfcentral.com Mon Aug 10 08:26:28 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 B628F3A6D05 for ; Mon, 10 Aug 2009 08:26:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.486 X-Spam-Level: X-Spam-Status: No, score=-2.486 tagged_above=-999 required=5 tests=[AWL=0.113, 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 0RlP3CdWC0hs for ; Mon, 10 Aug 2009 08:26:28 -0700 (PDT) Received: from n19.bullet.mail.mud.yahoo.com (n19.bullet.mail.mud.yahoo.com [68.142.206.146]) by core3.amsl.com (Postfix) with SMTP id D418A3A6CC7 for ; Mon, 10 Aug 2009 08:26:27 -0700 (PDT) Received: from [68.142.200.221] by n19.bullet.mail.mud.yahoo.com with NNFMP; 10 Aug 2009 15:26:30 -0000 Received: from [68.142.201.66] by t9.bullet.mud.yahoo.com with NNFMP; 10 Aug 2009 15:26:29 -0000 Received: from [127.0.0.1] by omp418.mail.mud.yahoo.com with NNFMP; 10 Aug 2009 15:26:29 -0000 X-Yahoo-Newman-Id: 955416.18766.bm@omp418.mail.mud.yahoo.com Received: (qmail 36941 invoked from network); 10 Aug 2009 15:26:29 -0000 Received: from unknown (HELO ?192.168.0.10?) (andy@67.125.157.61 with plain) by smtp110.sbc.mail.sp1.yahoo.com with SMTP; 10 Aug 2009 15:26:29 -0000 X-YMail-OSG: NJ.AnKUVM1nnH5AIQK8fbysjKmT8faoUA6jhtIZzchlanl9DpiUNiRnKbhG_mn4Ou8XiWQ7UOsvx_cVuGw3Lrf.PYCfv_S2buFHtaixdf36brE0x_0VaZM3pzR7P1TSyLSLz5Cbpy2N_.JsJKS2GPcJ7nYZxDNS60Zg4QdPVCYO8FYqTIv.9fVnKe5kZ9dc2fmy_ctwncY2eCKH95bMnbN6dhTawOMLSAELLvicP0ItrvAogDah6UyCSj1JtWzUBeenAAGSLOwYrFFDO2SABZfq7T01l0jXSTsRVOZFyme71przuu8jMLNuLvfKYQJBQ7nCjqE8ZGctDmYYBvthCVQ4RcifOEJu5v5SiookT4vK97.DH X-Yahoo-Newman-Property: ymail-3 Message-ID: <4A803C72.4000309@netconfcentral.com> Date: Mon, 10 Aug 2009 08:27:46 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.22 (X11/20090608) MIME-Version: 1.0 To: Martin Bjorklund References: <4A7EE8C6.5080706@netconfcentral.com> <20090810.144342.123608842.mbj@tail-f.com> In-Reply-To: <20090810.144342.123608842.mbj@tail-f.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: netconf@ietf.org Subject: Re: [Netconf] validate-1.1 capability 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, 10 Aug 2009 15:26:28 -0000 Martin Bjorklund wrote: > Hi, > > Andy Bierman wrote: >> Hi, >> >> The validate-1.1 capability is somewhat broken. > > [...] > >> So I don't want to fix it with a band-aid like this validate-1.1 >> capability. > > validate-1.1 adds one optional enumeration value. It does not try to > fix the problem you raise at all, so I don't see how it is a band-aid > for this problem. I would rather the standard used a new leaf for this purpose, and put it in a new 'test-only' YANG feature, instead of using the :validate capability at all. Capabilities are evil. They cannot be automated. They are buried in multiple sections or multiple RFCs, and the interactions are hard to figure out. The overloading of multiple capabilities on a single XML element is really awful. Use another leaf. We can make more. It's ok. We should use if-feature instead. > >> I would prefer to see all the validate capability >> be mandatory (including rollback-on-error), but this >> would mean a new protocol version. > > +1, but I'm not sure that this is important enough (on its own) to > warrant a new protocol version. > Depends if a better confirmed-commit procedure is on the table. Better to wait for that. At some point, we are going to need to 'roll up' many of the tiny little options into a new protocol version. I would like to see :validate and :xpath be mandatory to implement in version 2. > > > /martin > Andy From mehmet.ersue@nsn.com Mon Aug 10 08:39: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 0FBA03A6C49 for ; Mon, 10 Aug 2009 08:39:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.259 X-Spam-Level: X-Spam-Status: No, score=-3.259 tagged_above=-999 required=5 tests=[AWL=-0.661, 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 tBqNM780GgvE for ; Mon, 10 Aug 2009 08:39:16 -0700 (PDT) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [217.115.75.234]) by core3.amsl.com (Postfix) with ESMTP id 1FC6A3A6E9F for ; Mon, 10 Aug 2009 08:38:56 -0700 (PDT) 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 n7AFcw5e002808 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 10 Aug 2009 17:38:58 +0200 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 n7AFcvnN011005; Mon, 10 Aug 2009 17:38:57 +0200 Received: from DEMUEXC005.nsn-intra.net ([10.150.128.17]) by demuexc024.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Mon, 10 Aug 2009 17:38:57 +0200 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_01CA19D0.AC5F754A" Date: Mon, 10 Aug 2009 17:38:56 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Proposal to have YANG as normative for the Monitoring draft Thread-Index: AcoZ0Kw1GCf3ZnPtSf+WjP3XScrI1Q== From: "Ersue, Mehmet (NSN - DE/Munich)" To: X-OriginalArrivalTime: 10 Aug 2009 15:38:57.0687 (UTC) FILETIME=[ACD2D270:01CA19D0] Subject: [Netconf] Proposal to have YANG as normative for the 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: Mon, 10 Aug 2009 15:39:18 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CA19D0.AC5F754A Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dear NETCONF WG, after Juergen found out that we still have some effort for the IP=20 address issue and to finalize the monitoring draft we the WG chairs=20 discussed the issue with our AD and the I-D co-authors and by=20 hindsight believe that a strategy change would be better.=20 Therefor we want to propose to use YANG as the normative language=20 for the NETCONF monitoring draft to avoid inconsistencies with XSD=20 and if necessary to delay the publication until YANG gets published. For the sake of the document stability we accept the process delay which might be caused. We know already that some of the WG members are in favor of this.=20 But if anyone has STRONG objections and wants to stick to XSD as=20 the normative modeling language then please speak up and state=20 your opinion. PS: The question whether to keep the XSD model in the draft or not,=20 if yes, whether to model it manually or to generate via a well-known=20 tool can be discussed further on the maillist. Thank you. Mehmet & Bert > -----Original Message----- > From: netconf-bounces@ietf.org=20 > [mailto:netconf-bounces@ietf.org] On Behalf Of ext Juergen=20 > Schoenwaelder > Sent: Friday, August 07, 2009 4:45 PM > To: netconf@ietf.org > Subject: [Netconf] ip address types in the monitoring draft >=20 > Hi, >=20 > I checked the IPv4 and IPv6 address types in the XSD and in yang-types > and they are both different. This means that the sourceHost accepts > slightly different things if you compare the XSD and YANG versions of > the data models. >=20 > Now, the IPv4 pattern can be made the same by copying (and hoping the > yang-types patter won't change anymore). For the IPv6 pattern, things > are slightly more complicated since the YANG module makes use of the > YANG feature to have multiple pattern; this would translate into an > additional intermediate type for the XSD schema. >=20 > /js >=20 > --=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 >=20 ------_=_NextPart_001_01CA19D0.AC5F754A Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Proposal to have YANG as normative for the Monitoring draft =

Dear NETCONF WG,

after Juergen found out that we still = have some effort for the IP
address issue and to finalize the = monitoring draft we the WG chairs
discussed the issue with our AD and = the I-D co-authors and by
hindsight believe that a strategy = change would be better.

Therefor we want to propose to use = YANG as the normative language
for the NETCONF monitoring draft to = avoid inconsistencies with XSD
and if necessary to delay the = publication until YANG gets published.
For the sake of the document = stability we accept the process delay
which might be caused.

We know already that some of the WG = members are in favor of this.
But if anyone has STRONG objections = and wants to stick to XSD as
the normative modeling language then = please speak up and state
your opinion.

PS: The question whether to keep the = XSD model in the draft or not,
if yes, whether to model it manually = or to generate via a well-known
tool can be discussed further on the = maillist.

Thank you.

Mehmet & Bert


> -----Original = Message-----
> From: = netconf-bounces@ietf.org
> [mailto:netconf-bounces@ietf.org] On Behalf Of ext Juergen
> Schoenwaelder
> Sent: Friday, August 07, = 2009 4:45 PM
> To: netconf@ietf.org
> Subject: [Netconf] ip = address types in the monitoring draft
>
> Hi,
>
> I checked the IPv4 and IPv6 = address types in the XSD and in yang-types
> and they are both = different. This means that the sourceHost accepts
> slightly different things = if you compare the XSD and YANG versions of
> the data models.
>
> Now, the IPv4 pattern can = be made the same by copying (and hoping the
> yang-types patter won't = change anymore). For the IPv6 pattern, things
> are slightly more = complicated since the YANG module makes use of the
> YANG feature to have = multiple pattern; this would translate into an
> additional intermediate = type for the XSD schema.
>
> /js
>
> --
> Juergen = Schoenwaelder          = Jacobs University Bremen gGmbH
> Phone: +49 421 200 = 3587         Campus Ring 1, = 28759 Bremen, Germany
> Fax:   +49 421 = 200 3103         <http://www.jacobs-university.de/>
> = _______________________________________________
> Netconf mailing list
> Netconf@ietf.org
> https://www.ietf.org/mailman/listinfo/netconf
>

------_=_NextPart_001_01CA19D0.AC5F754A-- From andy@netconfcentral.com Mon Aug 10 08:39: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 4A85A3A6C49 for ; Mon, 10 Aug 2009 08:39:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.32 X-Spam-Level: X-Spam-Status: No, score=-2.32 tagged_above=-999 required=5 tests=[AWL=-0.055, 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 uYTwt7Pksqb5 for ; Mon, 10 Aug 2009 08:39:38 -0700 (PDT) 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 B1D8A3A6E8A for ; Mon, 10 Aug 2009 08:39:22 -0700 (PDT) Received: (qmail 29458 invoked from network); 10 Aug 2009 15:39:25 -0000 Received: from unknown (HELO ?192.168.0.10?) (andy@67.125.157.61 with plain) by smtp126.sbc.mail.sp1.yahoo.com with SMTP; 10 Aug 2009 15:39:24 -0000 X-YMail-OSG: jbcTnAgVM1mXKPpvbpmzpu6E6NJCvdIHV_cXb2zFIptSZ9CiXYZCmppv7b7pjaOaTqOlM_RNO7Se4kvqH.2fuqQ2qLtv4zkXeYc0C0_QkD.jIMmf.1.u2_rNxiBIHn1Xcc84L3ml6STtxhA9OgIpvqcJ4kihsS.gKPKWm7Ogp81f7BuB6I5tiG.NiGvMinmhozPfuuZ1hFAx2BYPg2Dq68skaugKxbs336_NzKj9c5LmpvZs8fiM.S926VsIwzsiI7RmQSwol.aWeDZGlm8MxzMUhzctQoKijcdmRJpc.BcZVlPDOGLwKntgxWF4JEMoqgdhl5inS1njEIlfvlY7LNw- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4A803F7A.6080901@netconfcentral.com> Date: Mon, 10 Aug 2009 08:40:42 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.22 (X11/20090608) MIME-Version: 1.0 To: Martin Bjorklund References: <4A7473F3.5080709@netconfcentral.com> <200908081440.n78EeQGu046784@idle.juniper.net> <20090810.151812.267824031.mbj@tail-f.com> In-Reply-To: <20090810.151812.267824031.mbj@tail-f.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: netconf@ietf.org Subject: Re: [Netconf] partial locking for candidate and startup? 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, 10 Aug 2009 15:39:39 -0000 Martin Bjorklund wrote: > Hi, > > Phil Shafer wrote: >> Andy Bierman writes: >>> Are there any plans to extend the partial locking >>> feature to the candidate and startup databases? >> The opposite. I've asked that explicit language >> be added to the partial lock draft saying that >> it is not compatible with :candidate, since partial >> locking with full commits is a non-starter. > > For the candidate, it has been said before that partial-locking does > no more harm to the full commit model of the candidate than a > candidate with no locks what so ever (which is supported by 4741). > I would spin it the other way... Using partial-lock on candidate is as useful as not using any locks at all. The fact there there is exactly one corner-case (path=/) that actually works is not impressive either. > For startup, I think it makes sense to remove partial-lock, since we > have clarified in 4741bis that startup cannot be modified with > edit-config. > > > /martin > Andy From cfinss@dial.pipex.com Mon Aug 10 10:24:44 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 3F2A328C14D for ; Mon, 10 Aug 2009 10:24:44 -0700 (PDT) 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.569, 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 8VYmuL9LIZt2 for ; Mon, 10 Aug 2009 10:24:43 -0700 (PDT) Received: from mk-outboundfilter-2.mail.uk.tiscali.com (mk-outboundfilter-2.mail.uk.tiscali.com [212.74.114.38]) by core3.amsl.com (Postfix) with ESMTP id 14FF23A6EEF for ; Mon, 10 Aug 2009 10:24:13 -0700 (PDT) X-Trace: 240559394/mk-outboundfilter-2.mail.uk.tiscali.com/PIPEX/$PIPEX-ACCEPTED/pipex-customers/62.188.100.6/None/cfinss@dial.pipex.com X-SBRS: None X-RemoteIP: 62.188.100.6 X-IP-MAIL-FROM: cfinss@dial.pipex.com X-SMTP-AUTH: X-MUA: Microsoft Outlook Express 6.00.2800.1106Produced By Microsoft MimeOLE V6.00.2800.1106 X-IP-BHB: Once X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ArMEAMv0f0o+vGQG/2dsb2JhbACDMI0+wDEJhA8Fgic X-IronPort-AV: E=Sophos;i="4.43,354,1246834800"; d="scan'208";a="240559394" X-IP-Direction: IN Received: from 1cust6.tnt1.lnd9.gbr.da.uu.net (HELO allison) ([62.188.100.6]) by smtp.pipex.tiscali.co.uk with SMTP; 10 Aug 2009 18:24:16 +0100 Message-ID: <001501ca19d6$e393f220$0601a8c0@allison> From: "tom.petch" To: "Andy Bierman" References: <200908081426.n78EQgOs046620@idle.juniper.net> <4A7D933E.7090307@netconfcentral.com> Date: Mon, 10 Aug 2009 18:21:36 +0200 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.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Cc: netconf@ietf.org Subject: Re: [Netconf] Comments on draft-ietf-netconf-monitoring-06.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: "tom.petch" List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Aug 2009 17:24:44 -0000 ----- Original Message ----- From: "Andy Bierman" To: "Phil Shafer" Cc: Sent: Saturday, August 08, 2009 5:01 PM > Phil Shafer wrote: > > Martin Bjorklund writes: > ... > >>> (a) should ietf models be under a top-level "/ietf/" container? > >> As Andy said this has been discussed and resolved before. Adding this > >> hierarchy would just add unnecessay containers. The namespace URI > >> provides the context for the top-level node. > > > > These "unnecessary containers" provide an organizational hierarchy. > > Without this, all modules will appear at the top level. This would > > be an unbearable bad decision. > > > > If there are 10 bgp yang modules, how do I say "give me all your > > bgp config" to a device? I can't just ask for the > > /ietf/protocols/routing/bgp hiearchy and get all 10 overlapping > > (augmented) module contents. > > I brought up the data hierarchy issue about 4 years ago > at the Santa Clara interim. Glad to see the issue again. > Sorry the situation has only got worse. > > I agree that we should have top level classes. > I am so sick of this ad-hoc, kitchen-sink design focus, > that almost anything at all would be better. > > But /ietf will get huge over time. So each WG should > decide its own container names, and not be forced to > use a simple formula like ietf-. > > /ietf-bgp/ > /ietf-netconf/ > > So why don't we have any sort of data organization in NETCONF, > so other WGs can follow our good example? Why > don't we start organizing and structuring data > so we stop setting such a bad example? With yang, I thought that, implicitly, we had had this discussion, but perhaps not. XPath absolute expressions need to know where the root is and currently, this does not make any allowance for /ietf/bgp/..., rather placing it above 'all top-level data nodes in all modules' Which is ok, as long as we never need an XPath expression which takes cognizance of /ietf/bgp/..; at which point, my crystal ball goes a little hazy. Tom Petch > > ... > > Thanks, > > Phil > > > > Andy From mbj@tail-f.com Tue Aug 11 02:13: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 2148B3A6D73 for ; Tue, 11 Aug 2009 02:13:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[AWL=0.068, 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 4a8M8oN+m7fM for ; Tue, 11 Aug 2009 02:13:29 -0700 (PDT) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id 2533E3A6FD2 for ; Tue, 11 Aug 2009 02:13:28 -0700 (PDT) Received: from localhost (138.162.241.83.in-addr.dgcsystems.net [83.241.162.138]) by mail.tail-f.com (Postfix) with ESMTPSA id 788FC76C5EC; Tue, 11 Aug 2009 11:13:31 +0200 (CEST) Date: Tue, 11 Aug 2009 11:13:31 +0200 (CEST) Message-Id: <20090811.111331.253454198.mbj@tail-f.com> To: mehmet.ersue@nsn.com From: Martin Bjorklund In-Reply-To: References: X-Mailer: Mew version 6.0.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 minutes for IETF #75 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: Tue, 11 Aug 2009 09:13:30 -0000 Hi, "Ersue, Mehmet (NSN - DE/Munich)" wrote: > ** 014: capability changes > > - AB says that the base capability version must be increase when adding new > error-app-tags, otherwise the existing managers will break. I believe Andy said 'error-tag' not 'error-app-tag'. > ** 010: namespace wildcarding > > - MB is in favour of treating no namespace as a wildcard > - BL says this wildcarding is often used and he likes it > - MB disagrees. > - AB says this does break XML I believe my disagreement was with Andy's comment, i.e. switch the last two lines. /martin From mbj@tail-f.com Tue Aug 11 03:39:42 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 9D9FB3A6B87 for ; Tue, 11 Aug 2009 03:39:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.966 X-Spam-Level: X-Spam-Status: No, score=-1.966 tagged_above=-999 required=5 tests=[AWL=0.080, 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 VsMj+2dUofrP for ; Tue, 11 Aug 2009 03:39:42 -0700 (PDT) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id 3FDA53A7081 for ; Tue, 11 Aug 2009 03:39:26 -0700 (PDT) Received: from localhost (138.162.241.83.in-addr.dgcsystems.net [83.241.162.138]) by mail.tail-f.com (Postfix) with ESMTPSA id 9C01376C59C; Tue, 11 Aug 2009 12:39:29 +0200 (CEST) Date: Tue, 11 Aug 2009 12:39:29 +0200 (CEST) Message-Id: <20090811.123929.57086703.mbj@tail-f.com> To: phil@juniper.net From: Martin Bjorklund In-Reply-To: <200908101400.n7AE0DCx059174@idle.juniper.net> References: <20090809205432.GA4430@elstar.local> <200908101400.n7AE0DCx059174@idle.juniper.net> X-Mailer: Mew version 6.0.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] Fw: Database Architecture OK or NOT-OK? 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, 11 Aug 2009 10:39:42 -0000 Phil Shafer wrote: > Juergen Schoenwaelder writes: > >Do you blow away changes that were made to running? > > I don't support :writable-running, just :candidate, and the > interaction between the two isn't clear. Martin, how does > this work on your sw? There is no magic going on just beacuse the box is configured to use both :candidate and :writable-running. Each operation behaves the same regardless of the other capabilites. So resets candidate to the contents of running, and replaces running with the contents of candidate. I agree that it is a burden on the client software to support all different combinations of (startup, writable-running, candidate), and a server developer that has a choice should carefully consider which combination to implement. When both :candidate and :writable-running are advertised, a client that wants to use the candidate (maybe in order to use a confirmed commit), should do: do { lock(running) discard-changes() lock(candidate) } until candidate is locked edit-config(candidate, ...) commit() Or, as was discussed before, don't do the loop and fail if the lock on candidate cannot be acquired. /martin From andy@netconfcentral.com Tue Aug 11 05:24: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 DBEB63A6F65 for ; Tue, 11 Aug 2009 05:24:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.481 X-Spam-Level: X-Spam-Status: No, score=-2.481 tagged_above=-999 required=5 tests=[AWL=0.118, 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 n+hi0dukFPHY for ; Tue, 11 Aug 2009 05:24:47 -0700 (PDT) Received: from n12a.bullet.mail.mud.yahoo.com (n12a.bullet.mail.mud.yahoo.com [209.191.125.177]) by core3.amsl.com (Postfix) with SMTP id 18A9D3A6A43 for ; Tue, 11 Aug 2009 05:24:47 -0700 (PDT) Received: from [209.191.108.96] by n12.bullet.mail.mud.yahoo.com with NNFMP; 11 Aug 2009 12:23:18 -0000 Received: from [68.142.201.254] by t3.bullet.mud.yahoo.com with NNFMP; 11 Aug 2009 12:23:18 -0000 Received: from [127.0.0.1] by omp415.mail.mud.yahoo.com with NNFMP; 11 Aug 2009 12:23:18 -0000 X-Yahoo-Newman-Id: 540902.32366.bm@omp415.mail.mud.yahoo.com Received: (qmail 1382 invoked from network); 11 Aug 2009 12:23:18 -0000 Received: from unknown (HELO ?192.168.0.10?) (andy@67.125.157.61 with plain) by smtp101.sbc.mail.sp1.yahoo.com with SMTP; 11 Aug 2009 12:23:17 -0000 X-YMail-OSG: t91W0UoVM1n0xas0jemiWH1PqbBV4W3AfcttgWTIE_frP1ldsv_qIDzWFtTjfqwsDawjQGbjtmySJXh6nNhX4qfQQ3oLqPf0Vyal4CijEh_baxOXHobaVoJ8WZggsG2y26e3sD1vzqDjXA7C9q.d.F0nY2zl9dSz12dZDQOdq9pInV_bAW3PViXDKfSYPlkubwa61rSINQPk86ECQZwhEGC9sECq4sgJfdq7q1ndE5XXrso.iqARp68LLjWO8qNchBTZ.0rcNdTxeb314Br2CeXM2WI93CCfJO4x_0y5Tu4zgA-- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4A816308.10901@netconfcentral.com> Date: Tue, 11 Aug 2009 05:24:40 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.22 (X11/20090608) MIME-Version: 1.0 To: Martin Bjorklund References: <20090811.111331.253454198.mbj@tail-f.com> In-Reply-To: <20090811.111331.253454198.mbj@tail-f.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: netconf@ietf.org Subject: Re: [Netconf] Draft minutes for IETF #75 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: Tue, 11 Aug 2009 12:24:48 -0000 Martin Bjorklund wrote: > Hi, > > "Ersue, Mehmet (NSN - DE/Munich)" wrote: >> ** 014: capability changes >> >> - AB says that the base capability version must be increase when adding new >> error-app-tags, otherwise the existing managers will break. > > I believe Andy said 'error-tag' not 'error-app-tag'. > >> ** 010: namespace wildcarding >> >> - MB is in favour of treating no namespace as a wildcard >> - BL says this wildcarding is often used and he likes it >> - MB disagrees. >> - AB says this does break XML > > I believe my disagreement was with Andy's comment, i.e. switch the > last two lines. > I no longer object to this wildcarding. Turns out I already implemented it ;-) I checked my code and it does the same thing as Martin is suggesting. I don't even care if you declare the NULL namespace prefix or not: eth0 This XML above does not break the libxml2 parser, so I was wrong in my comment on jabber. If there is a way to make life easier on the operator, then I don't care if it's standard or not, so the NETCONF namespace can be left out too: But if namespaces are used, they must be correct. > > > /martin Andy From j.schoenwaelder@jacobs-university.de Tue Aug 11 07:27:28 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 8D0F23A6AE1 for ; Tue, 11 Aug 2009 07:27:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.161 X-Spam-Level: X-Spam-Status: No, score=-2.161 tagged_above=-999 required=5 tests=[AWL=0.088, 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 h5BapJQkZA6Z for ; Tue, 11 Aug 2009 07:27:27 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 7070C3A68A3 for ; Tue, 11 Aug 2009 07:27:27 -0700 (PDT) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 64E5CC002F; Tue, 11 Aug 2009 16:25:17 +0200 (CEST) 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 FFH0NP3h8G-E; Tue, 11 Aug 2009 16:25:16 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id E4BA2C0029; Tue, 11 Aug 2009 16:25:15 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id C5BD5C3B7A6; Tue, 11 Aug 2009 16:25:14 +0200 (CEST) Date: Tue, 11 Aug 2009 16:25:14 +0200 From: Juergen Schoenwaelder To: Phil Shafer Message-ID: <20090811142514.GB1042@elstar.local> Mail-Followup-To: Phil Shafer , Andy Bierman , "netconf@ietf.org" References: <4A7F20EB.2010002@netconfcentral.com> <200908101321.n7ADLxqS058788@idle.juniper.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200908101321.n7ADLxqS058788@idle.juniper.net> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: "netconf@ietf.org" Subject: Re: [Netconf] Comments on draft-ietf-netconf-monitoring-06.txt 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, 11 Aug 2009 14:27:28 -0000 On Mon, Aug 10, 2009 at 03:21:59PM +0200, Phil Shafer wrote: > Andy Bierman writes: > >but this is protocol name, not WG name. > > There should be an organization above the protocol name containing > the area on which the protocol works. At a minimum, this could be > the ietf area, but something better (perhaps determined by the > area directors for that area?) should be easily possible. > > A strawman: > > /ietf > + /protocols > + /management > + /snmp > + /netconf > + /routing > + /bgp > + /ospf > + /layer-2 > + /spanning-tree > + /mpls > + /path-management > + /rvsp > + /ldp > + /security > + /ipsec > + /eap > + /ipr > + /lawyer-fodder > > Or: > > /ietf > + /area > + /applications > + /general > + /internet > + /oam > + /netconf > + /snmp > + /real-time > + /routing > + /mpls > + /rsvp > + /ldp > + /bgp > + /security > + /transport > + /other > > Or perhaps put bgp under "egp" and "ospf" and "isis" under "igp". Areas come and go, protocols move between areas, everything is tunneled on top and below everything else (almost). So I believe the only sensible long lasting structure is /ietf/snmp netconf bgp mpls ... and since we use proper namespaces, even the /ietf is not really adding much in terms of XML processing. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From wjhns1@hardakers.net Tue Aug 11 07:47:42 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 8B7E93A67ED for ; Tue, 11 Aug 2009 07:47:42 -0700 (PDT) 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 9xojn6thpwsO for ; Tue, 11 Aug 2009 07:47:41 -0700 (PDT) Received: from mail.hardakers.net (hardaker-pt.tunnel.tserv1.fmt.ipv6.he.net [IPv6:2001:470:1f00:ffff::af]) by core3.amsl.com (Postfix) with ESMTP id 990F43A6EC1 for ; Tue, 11 Aug 2009 07:47:41 -0700 (PDT) Received: from localhost (wjh.hardakers.net [10.0.0.2]) by mail.hardakers.net (Postfix) with ESMTPSA id 7AA2B98257; Tue, 11 Aug 2009 07:47:42 -0700 (PDT) From: Wes Hardaker To: Tomasz Mikolajczyk Organization: Sparta References: <20090804095639.GA21611@elstar.local> <4A784734.7080201@netconfcentral.com> <20090804144838.GA962@elstar.local> <4A784E8E.8000007@netconfcentral.com> <20090804184136.GC1038@elstar.local> <4A788A66.4030106@bwijnen.net> <20090804211449.GA1307@elstar.local> <4A78AA22.4070405@netconfcentral.com> <4A79873D.1030007@netconfcentral.com> <20090805143434.GB2612@elstar.local> <4A799E9D.4050605@s3group.com> Date: Tue, 11 Aug 2009 07:47:41 -0700 In-Reply-To: <4A799E9D.4050605@s3group.com> (Tomasz Mikolajczyk's message of "Wed, 05 Aug 2009 17:00:45 +0200") Message-ID: User-Agent: Gnus/5.110011 (No Gnus v0.11) XEmacs/21.4.21 (linux, no MULE) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Netconf Subject: Re: [Netconf] Fw: Database Architecture OK or NOT-OK? 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, 11 Aug 2009 14:47:42 -0000 >>>>> On Wed, 05 Aug 2009 17:00:45 +0200, Tomasz Mikolajczyk said: TM> I brought this lock issue up over a half year ago. Here is that thread: TM> http://www.ietf.org/mail-archive/web/netconf/current/msg03992.html Going back further you'll find I gave a whole presentation in San Diego about the issues surrounding the fact that we expect to have multiple potential editors operating on unique databases but the operation to move data from one (candidate) to another (running) is a complete copy. This is in no way a good design if multiple managers are involved (and has security ramifications if the managers don't have global access rights). The netconf databases are designed to be used by a single manager with absolute control or else all sort of things start to "pop up" like this. In real life no one does "cp /dev/disk1 /dev/disk2" in order to copy a subset of stuff from one storage system to another. The discussion, reading it a bit late, sure makes it look like a netconf-bis that completely replaces the original would be a good thing at this point. -- Wes Hardaker Cobham Analytic Solutions From phil@juniper.net Tue Aug 11 08:00: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 C15523A6DC8 for ; Tue, 11 Aug 2009 08:00:45 -0700 (PDT) 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 lBgkPPy7ihUr for ; Tue, 11 Aug 2009 08:00:45 -0700 (PDT) Received: from exprod7og110.obsmtp.com (exprod7og110.obsmtp.com [64.18.2.173]) by core3.amsl.com (Postfix) with ESMTP id E7BCA3A6D9A for ; Tue, 11 Aug 2009 08:00:43 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob110.postini.com ([64.18.6.12]) with SMTP ID DSNKSoGHUIMGGecwG4ufbehOE102ggr5QJEk@postini.com; Tue, 11 Aug 2009 08:00:49 PDT 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, 11 Aug 2009 07:51:53 -0700 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, 11 Aug 2009 07:51:53 -0700 Received: from emailsmtp55.jnpr.net ([172.24.18.132]) by p-emlb02-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 11 Aug 2009 07:51:53 -0700 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp55.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 11 Aug 2009 07:51:52 -0700 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 n7BEpqd77165; Tue, 11 Aug 2009 07:51:52 -0700 (PDT) (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 n7BEe94L067758; Tue, 11 Aug 2009 14:40:09 GMT (envelope-from phil@idle.juniper.net) Message-ID: <200908111440.n7BEe94L067758@idle.juniper.net> To: Juergen Schoenwaelder In-Reply-To: <20090811142514.GB1042@elstar.local> Date: Tue, 11 Aug 2009 10:40:09 -0400 From: Phil Shafer X-OriginalArrivalTime: 11 Aug 2009 14:51:52.0655 (UTC) FILETIME=[4362E5F0:01CA1A93] MIME-Version: 1.0 Content-Type: text/plain Cc: "netconf@ietf.org" Subject: Re: [Netconf] Comments on draft-ietf-netconf-monitoring-06.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: Tue, 11 Aug 2009 15:00:45 -0000 Juergen Schoenwaelder writes: >Areas come and go, protocols move between areas, everything is >tunneled on top and below everything else (almost). Surely there's some organizational approach that makes sense. A "flat earth" view where thousands of namespaces live at one layer can't survive the sniff test. snmp and netconf are management protocols. bgp and ospf are routing protocols. mpls is a switching protocol. These aren't fluid. Sure, you can run http over dns or use bgp to calculate the shortest path from your house to your office, but that doesn't change their principle use. Thanks, Phil From j.schoenwaelder@jacobs-university.de Tue Aug 11 08:14: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 C33253A6F65 for ; Tue, 11 Aug 2009 08:14:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.163 X-Spam-Level: X-Spam-Status: No, score=-2.163 tagged_above=-999 required=5 tests=[AWL=0.086, 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 oMwUlD7wFsQG for ; Tue, 11 Aug 2009 08:14:40 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 2D9153A703F for ; Tue, 11 Aug 2009 08:13:44 -0700 (PDT) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 856D8C002F; Tue, 11 Aug 2009 17:11:48 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius4.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id HD2e4OlJSsrj; Tue, 11 Aug 2009 17:11:47 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 14618C0029; Tue, 11 Aug 2009 17:11:47 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id EF063C3BB1A; Tue, 11 Aug 2009 17:11:45 +0200 (CEST) Date: Tue, 11 Aug 2009 17:11:45 +0200 From: Juergen Schoenwaelder To: Phil Shafer Message-ID: <20090811151145.GF1042@elstar.local> Mail-Followup-To: Phil Shafer , Andy Bierman , "netconf@ietf.org" References: <20090811142514.GB1042@elstar.local> <200908111440.n7BEe94L067758@idle.juniper.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200908111440.n7BEe94L067758@idle.juniper.net> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: "netconf@ietf.org" Subject: Re: [Netconf] Comments on draft-ietf-netconf-monitoring-06.txt 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, 11 Aug 2009 15:14:40 -0000 On Tue, Aug 11, 2009 at 04:40:09PM +0200, Phil Shafer wrote: > snmp and netconf are management protocols. bgp and ospf are > routing protocols. mpls is a switching protocol. These aren't > fluid. Sure, you can run http over dns or use bgp to calculate > the shortest path from your house to your office, but that doesn't > change their principle use. These were the simple examples - there is other stuff I do not find so clear cut. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From j.schoenwaelder@jacobs-university.de Tue Aug 11 08:44: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 D0BFF3A6B91 for ; Tue, 11 Aug 2009 08:44:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.164 X-Spam-Level: X-Spam-Status: No, score=-2.164 tagged_above=-999 required=5 tests=[AWL=0.085, 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 lqFGimscxRmp for ; Tue, 11 Aug 2009 08:44:57 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id B37343A6FC3 for ; Tue, 11 Aug 2009 08:44:56 -0700 (PDT) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 6F546C0030; Tue, 11 Aug 2009 17:44:04 +0200 (CEST) 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 wzcPN7J30RrQ; Tue, 11 Aug 2009 17:44:03 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 3F218C002F; Tue, 11 Aug 2009 17:44:03 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 228B7C3BCA4; Tue, 11 Aug 2009 17:44:01 +0200 (CEST) Date: Tue, 11 Aug 2009 17:44:01 +0200 From: Juergen Schoenwaelder To: Phil Shafer Message-ID: <20090811154401.GA1479@elstar.local> Mail-Followup-To: Phil Shafer , Andy Bierman , Netconf References: <20090809205432.GA4430@elstar.local> <200908101400.n7AE0DCx059174@idle.juniper.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200908101400.n7AE0DCx059174@idle.juniper.net> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: Netconf Subject: Re: [Netconf] Fw: Database Architecture OK or NOT-OK? 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, 11 Aug 2009 15:44:58 -0000 On Mon, Aug 10, 2009 at 04:00:12PM +0200, Phil Shafer wrote: > >Since candidate is a shared buffer, how can I every > >use discard-changes() in a save way without having a proper lock? > > If there are outstanding changes, the software client cannot > make any serious assumption about their nature, so choosing > to blow them away is something best left to a human. So discard-changes() is only for situations where I have a lock or for humans? If this is so, I think this should be spelled out - otherwise I am sure someone will write an application that calls discard-changes() in order to acquire a lock... > >You seem to want to protect applications that do not use locks > >properly and I wonder how this is ever going to work. > > I don't see it this way. I want to protect applications that are > using locks in a responsible manner from dangerous interactions > with other sources of configuration that are not behaving well. > > >In other words, a session that causes > >candidate to be dirty (and see above that it is not clear what dirty > >means with :writable-running) and goes away will cause all other well > >written applications to stop working. > > Exactly. An client (human or sw) that leaves (or keeps) the box > in an undefined state is not a suitation that a non-ai piece of > software can reasonable resolve. Send an alarm and let something > smarter resolve it. But let me recap: 1) This behave well idea only works if all applications follow the same idea of responsible behaviour - so this needs to be documented somewhere since otherwise someone like me writes an application that simply calls discard-changes. 2) The candidate design does not work with :writeable-running unless we find a more precise definition how to determine whether candidate is in a "good shape" or not. > >Concrete question to you: Does the Junos CLI use locks or only when > >specifically asked to use locks? > > The candidate config in JUNOS is shared between all CLI users, and > locks are not mandatory. The "configure" command enters configuration > mode, and the "configure exclusive" command grabs the lock before > entering configuration mode. These same "dirty" rules apply. > > For three people working together to solve a, say, bgp policy problem, > using the shared workspace works well. But in the interaction between > humans and applications means, the human should always win. > > Hmmmm, the three laws of management applications: > (1) An automation may not break human configuration > or, through action or inaction, allow human configuration > to be broken. > (2) An automation must try to get it's job done, except > where such attempts would conflict with the First Law. > (3) An automation must protect its own existence, by > applying the First and Second Laws in a way that does > not tempt the human to turn it off. I might agree to the laws but I am not sure I agree that the current special semantics we have generally work. They might be working for the Junos combination of capabilities and applications written in the Junos spirit - where unlocked usage of candidate is strictly for humans. I am not sure this works in the wild with all the other legal combinations of capabilities we have and that people will have to write management applications for. /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 Tue Aug 11 10:41: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 C44823A6D81 for ; Tue, 11 Aug 2009 10:41:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.471 X-Spam-Level: X-Spam-Status: No, score=-2.471 tagged_above=-999 required=5 tests=[AWL=0.128, 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 5P1bTVA4g6Is for ; Tue, 11 Aug 2009 10:41:02 -0700 (PDT) Received: from n18.bullet.mail.mud.yahoo.com (n18.bullet.mail.mud.yahoo.com [68.142.206.145]) by core3.amsl.com (Postfix) with SMTP id B21F43A6A2F for ; Tue, 11 Aug 2009 10:40:58 -0700 (PDT) Received: from [68.142.200.221] by n18.bullet.mail.mud.yahoo.com with NNFMP; 11 Aug 2009 17:40:19 -0000 Received: from [68.142.201.254] by t9.bullet.mud.yahoo.com with NNFMP; 11 Aug 2009 17:40:19 -0000 Received: from [127.0.0.1] by omp415.mail.mud.yahoo.com with NNFMP; 11 Aug 2009 17:40:19 -0000 X-Yahoo-Newman-Id: 18931.84211.bm@omp415.mail.mud.yahoo.com Received: (qmail 96552 invoked from network); 11 Aug 2009 17:40:18 -0000 Received: from unknown (HELO ?192.168.0.10?) (andy@67.125.157.61 with plain) by smtp102.sbc.mail.sp1.yahoo.com with SMTP; 11 Aug 2009 17:40:18 -0000 X-YMail-OSG: hQXeyzIVM1kuuOSIJHVwfSMyj6XWSTyvAggnDzy0Jny8a66ppjJWbWoupBatfoXnBN8W8C7.s4ITLAY43W7zREI9QLiv34syreeHdNrEEInw7JCdMxRIWORZZhxm.mglZyIw7dB_lFVBq.gMBbEQUjsw6hGivUintG82hdx_DvBgncZFh4nfS.0xLwRrqFwCneHNts6YWxh7MHSfE.23yhr5GOr72XeKsa7xHCL4Pzo4Y8wTYr5TIR_zEpOEabGAMd.c.5wVND7AEnh5SpuvfqTXgsimg._jr_sWXZLkpEP32.gS8VY- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4A81AD56.8010408@netconfcentral.com> Date: Tue, 11 Aug 2009 10:41:42 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.22 (X11/20090608) MIME-Version: 1.0 To: Phil Shafer References: <200908111440.n7BEe94L067758@idle.juniper.net> In-Reply-To: <200908111440.n7BEe94L067758@idle.juniper.net> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "netconf@ietf.org" Subject: Re: [Netconf] Comments on draft-ietf-netconf-monitoring-06.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: Tue, 11 Aug 2009 17:41:03 -0000 Phil Shafer wrote: > Juergen Schoenwaelder writes: >> Areas come and go, protocols move between areas, everything is >> tunneled on top and below everything else (almost). > > Surely there's some organizational approach that makes sense. > A "flat earth" view where thousands of namespaces live at one > layer can't survive the sniff test. > I like the organization that Juergen proposed. I have to type XPath absolute path expressions a lot, and the extra containers do not add value. > snmp and netconf are management protocols. bgp and ospf are > routing protocols. mpls is a switching protocol. These aren't > fluid. Sure, you can run http over dns or use bgp to calculate > the shortest path from your house to your office, but that doesn't > change their principle use. > I think if (by some miracle) the IDR WG decides to standardize an ietf-bgp.yang module, then they can decide how many top-level elements in how many XML namespaces -- or maybe they will want to use submodules and have a giant ietf-routing.yang main module. I don't think the NETCONF or NETMOD WGs should make this decision for them. > Thanks, > Phil > Andy From mbj@tail-f.com Tue Aug 11 12:42: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 429FA3A6FD7 for ; Tue, 11 Aug 2009 12:42:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.971 X-Spam-Level: X-Spam-Status: No, score=-1.971 tagged_above=-999 required=5 tests=[AWL=0.075, 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 UWrgpBSmyBJB for ; Tue, 11 Aug 2009 12:42:51 -0700 (PDT) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id 49E603A6F7E for ; Tue, 11 Aug 2009 12:42:51 -0700 (PDT) Received: from localhost (c213-100-167-236.swipnet.se [213.100.167.236]) by mail.tail-f.com (Postfix) with ESMTPSA id 3E99A76C59C; Tue, 11 Aug 2009 21:36:11 +0200 (CEST) Date: Tue, 11 Aug 2009 21:36:10 +0200 (CEST) Message-Id: <20090811.213610.237587531.mbj@tail-f.com> To: andy@netconfcentral.com From: Martin Bjorklund In-Reply-To: <4A81AD56.8010408@netconfcentral.com> References: <200908111440.n7BEe94L067758@idle.juniper.net> <4A81AD56.8010408@netconfcentral.com> X-Mailer: Mew version 6.0.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] Comments on draft-ietf-netconf-monitoring-06.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: Tue, 11 Aug 2009 19:42:52 -0000 Andy Bierman wrote: > Phil Shafer wrote: > > Juergen Schoenwaelder writes: > >> Areas come and go, protocols move between areas, everything is > >> tunneled on top and below everything else (almost). > > > > Surely there's some organizational approach that makes sense. > > A "flat earth" view where thousands of namespaces live at one > > layer can't survive the sniff test. > > > > I like the organization that Juergen proposed. With or without /ietf? > I have to type XPath absolute path expressions > a lot, and the extra containers do not add value. I agree. We need to decide what we should do for the monitoring module and other netconf modules. We already have: {urn:ietf:params:xml:ns:netmod:notification}netconf (RFC 5277) and currently in the monitoring draft: {urn:ietf:params:xml:ns:netconf:state}netconf-state Maybe the next module will be ietf-netconf-acm, which actually will provide some configuration knobs! I don't think we can do much about 5277 at this point, but we should think about if we need a 'netconf' container under which we can put the current monitoring and future config models. Do we want to use many namespaces, or should we try to partition one namespace with submodules? Can we make one ietf-netconf module which defines the '/netconf' container and then publish the monitoring as a submodule and a future access control module as another submodule? /martin From andy@netconfcentral.com Tue Aug 11 12: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 AD3573A7040 for ; Tue, 11 Aug 2009 12:59:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.472 X-Spam-Level: X-Spam-Status: No, score=-2.472 tagged_above=-999 required=5 tests=[AWL=0.127, 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 HAwVVCSCut3C for ; Tue, 11 Aug 2009 12:59:38 -0700 (PDT) Received: from n14.bullet.mail.mud.yahoo.com (n14.bullet.mail.mud.yahoo.com [68.142.206.41]) by core3.amsl.com (Postfix) with SMTP id AA9FD3A6B05 for ; Tue, 11 Aug 2009 12:59:14 -0700 (PDT) Received: from [68.142.200.226] by n14.bullet.mail.mud.yahoo.com with NNFMP; 11 Aug 2009 19:56:23 -0000 Received: from [68.142.201.69] by t7.bullet.mud.yahoo.com with NNFMP; 11 Aug 2009 19:56:23 -0000 Received: from [127.0.0.1] by omp421.mail.mud.yahoo.com with NNFMP; 11 Aug 2009 19:56:23 -0000 X-Yahoo-Newman-Id: 293799.77245.bm@omp421.mail.mud.yahoo.com Received: (qmail 69249 invoked from network); 11 Aug 2009 19:56:22 -0000 Received: from unknown (HELO ?192.168.0.10?) (andy@67.125.157.61 with plain) by smtp108.sbc.mail.sp1.yahoo.com with SMTP; 11 Aug 2009 19:56:22 -0000 X-YMail-OSG: ZpQcEjQVM1kv9nl8.jbLyIsTUiT36ZWaJhyqBX62bYnT895tmNYmNfmIdkXOhu6aLvJxHnauUMoJKytLUwW7Zm2e9SA.3er0hS9qeEKmHnTOyru9eohq3f0LtrXwG7moFluUFwKjtFxEP3yQmBJ9qE9CcPrbX2xj2t2L4u2UzFvG7kiKDPq9p6U8GslF.Byq0q20PhYt3XnEimulqQNOGtv5SG9IZP3_u5CxjR5SvTBEiNR6v0rQlMQK1KWlbbk_GqQ.H.LZawCcQrajszcFJuAxQf0nyXhVmWetN6XU_CgZ3trOjI7DnyxzMgyDP7jGmxkvhMfZf_ahjJlB8gDVWTz_AQ28MCjkcX77w7Sh8wLIe0Uc X-Yahoo-Newman-Property: ymail-3 Message-ID: <4A81CD3A.5080509@netconfcentral.com> Date: Tue, 11 Aug 2009 12:57:46 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.22 (X11/20090608) MIME-Version: 1.0 To: Martin Bjorklund References: <200908111440.n7BEe94L067758@idle.juniper.net> <4A81AD56.8010408@netconfcentral.com> <20090811.213610.237587531.mbj@tail-f.com> In-Reply-To: <20090811.213610.237587531.mbj@tail-f.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: netconf@ietf.org Subject: Re: [Netconf] Comments on draft-ietf-netconf-monitoring-06.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: Tue, 11 Aug 2009 19:59:39 -0000 Martin Bjorklund wrote: > Andy Bierman wrote: >> Phil Shafer wrote: >>> Juergen Schoenwaelder writes: >>>> Areas come and go, protocols move between areas, everything is >>>> tunneled on top and below everything else (almost). >>> Surely there's some organizational approach that makes sense. >>> A "flat earth" view where thousands of namespaces live at one >>> layer can't survive the sniff test. >>> >> I like the organization that Juergen proposed. > > With or without /ietf? without > >> I have to type XPath absolute path expressions >> a lot, and the extra containers do not add value. > > I agree. We need to decide what we should do for the monitoring > module and other netconf modules. We already have: > > {urn:ietf:params:xml:ns:netmod:notification}netconf (RFC 5277) > > and currently in the monitoring draft: > > {urn:ietf:params:xml:ns:netconf:state}netconf-state > > Maybe the next module will be ietf-netconf-acm, which actually will > provide some configuration knobs! > > I don't think we can do much about 5277 at this point, but we should > think about if we need a 'netconf' container under which we can put > the current monitoring and future config models. > > Do we want to use many namespaces, or should we try to partition one > namespace with submodules? Can we make one ietf-netconf module which > defines the '/netconf' container and then publish the monitoring as a > submodule and a future access control module as another submodule? > We should not change published URIs, so the old format in RFC 5277 is 'legacy'. > > /martin > From mehmet.ersue@nsn.com Wed Aug 12 04:14: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 35A0B3A6A43; Wed, 12 Aug 2009 04:14:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.231 X-Spam-Level: X-Spam-Status: No, score=-5.231 tagged_above=-999 required=5 tests=[AWL=1.368, 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 lflUm2BIty+6; Wed, 12 Aug 2009 04:14:53 -0700 (PDT) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [217.115.75.233]) by core3.amsl.com (Postfix) with ESMTP id 883933A6A5E; Wed, 12 Aug 2009 04:14:05 -0700 (PDT) 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 n7CAH98a017903 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 12 Aug 2009 12:17:09 +0200 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 n7CAH7tO023496; Wed, 12 Aug 2009 12:17:09 +0200 Received: from DEMUEXC005.nsn-intra.net ([10.150.128.17]) by demuexc024.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 12 Aug 2009 12:17:09 +0200 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, 12 Aug 2009 12:17:07 +0200 Message-ID: In-Reply-To: <20090812.090057.122296722.mbj@tail-f.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [netmod] staying in synch on data model discovery Thread-Index: AcobGvUPRKKv4Q3BSv6jEChpd7T0IAAF/sKg References: <4A7EF28E.2040502@netconfcentral.com> <20090812.090057.122296722.mbj@tail-f.com> From: "Ersue, Mehmet (NSN - DE/Munich)" To: "ext Martin Bjorklund" , X-OriginalArrivalTime: 12 Aug 2009 10:17:09.0169 (UTC) FILETIME=[0CE04A10:01CA1B36] Cc: netconf@ietf.org, netmod@ietf.org Subject: Re: [Netconf] [netmod] staying in synch on data model discovery 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, 12 Aug 2009 11:14:54 -0000 Hi Andy, Martin, I think we should bring the discussion related to NETCONF Monitoring draft to the NETCONF maillist. Since we believed the monitoring draft was nearly final I would appreciate if you guys post clear requests possibly with a text proposal.=20 I think this will help the authors of the monitoring draft and the NETCONF WG a lot. One other question though as a contributor: NETCONF WG developed "capabilities" and introduced several of them. Is it your proposal they shouldn't be used? I am wondering whether we need a WG decision or BCP-like statement saying it shouldn't be used. It would be interesting if you elaborate a bit why YANG features should be used instead of NETCONF capabilities. (I know some of the reasons but might be missing others. At the end we need a record on the maillist if we want to push such a decision.) Mehmet =20 > -----Original Message----- > From: netmod-bounces@ietf.org=20 > [mailto:netmod-bounces@ietf.org] On Behalf Of ext Martin Bjorklund > Sent: Wednesday, August 12, 2009 9:01 AM > To: andy@netconfcentral.com > Cc: netmod@ietf.org > Subject: Re: [netmod] staying in synch on data model discovery >=20 > Hi Andy, >=20 > Andy Bierman wrote: > > I mostly care about the ietf-netconf-state data model to > > use the get-schema() operation with YANG. If others want > > XSD and RNG instead, then that's extra credit, but full > > support for YANG is a must-have. >=20 > I agree. >=20 > > YANG modules, submodules, and deviation modules all need > > to be listed in the and retrievable with . >=20 > Yes. That is the intention of the current design. >=20 > > However, deviations have no revision that is advertised, > > yet they clearly have a revision-date just like any other > > YANG module. This is somewhere between confusing and broken. >=20 > What makes you think that modules with deviation statements are not > advertised with their revision? >=20 > > The field in the operation is mandatory. > > It should be optional, and if missing, then the > > agent will pick whatever revision it wants (usually > > there will just be 1 to pick from). > >=20 > > The field in the operation is mandatory. > > It should be optional, and the default should be 'YANG'. >=20 > I agree that these two parameters should be made optional, but I think > that an error should be returned if there are multiple revisions > and/or formats. In most cases there will be just one revision and one > format so that's the one that will be returned. >=20 > > IMO, the use of capabilities instead of YANG features needs > > to stop. >=20 > Agreed. For the current drafts, I think this applies to partial-lock > which we don't want to change at this point, and with-defaults which I > believe Juergen commented on in some other thread. I think the > monitoring draft is fine. >=20 > > I think the node should have another leaf: > >=20 > > leaf moduleType { > > description > > "The type of data model file for this schema entry."; > > type enumeration { > > enum module { > > description > > "Indicates this entry is for a main module."; > > } > > enum submodule { > > description > > "Indicates this entry is for a sub-module."; > > } > > enum deviation { > > description > > "Indicates this entry is for a deviation module."; > > } > > enum other { > > description > > "Indicates this entry is for some other type of=20 > module."; > > } > > } > > } >=20 > I don't think this is necessary, and in any case, there is no such > thing as a 'deviation' module. In theory, any module / submodule can > have deviation statements. >=20 >=20 > /martin > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod >=20 From j.schoenwaelder@jacobs-university.de Wed Aug 12 04:35: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 CC41B3A69FF; Wed, 12 Aug 2009 04:35:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.166 X-Spam-Level: X-Spam-Status: No, score=-2.166 tagged_above=-999 required=5 tests=[AWL=0.083, 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 Hy6KV2--q7gi; Wed, 12 Aug 2009 04:35:30 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 9B1A63A69E4; Wed, 12 Aug 2009 04:35:30 -0700 (PDT) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 403C4C0053; Wed, 12 Aug 2009 13:32:55 +0200 (CEST) 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 7TlCQ8iD9lml; Wed, 12 Aug 2009 13:32:54 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 9291CC0051; Wed, 12 Aug 2009 13:32:53 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 7D7A5C64BA5; Wed, 12 Aug 2009 13:32:52 +0200 (CEST) Date: Wed, 12 Aug 2009 13:32:52 +0200 From: Juergen Schoenwaelder To: "Ersue, Mehmet (NSN - DE/Munich)" Message-ID: <20090812113252.GA12121@elstar.local> Mail-Followup-To: "Ersue, Mehmet (NSN - DE/Munich)" , ext Martin Bjorklund , "andy@netconfcentral.com" , "netconf@ietf.org" , "netmod@ietf.org" References: <4A7EF28E.2040502@netconfcentral.com> <20090812.090057.122296722.mbj@tail-f.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.20 (2009-06-14) Cc: "netconf@ietf.org" , "netmod@ietf.org" Subject: Re: [Netconf] [netmod] staying in synch on data model discovery 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, 12 Aug 2009 11:35:31 -0000 On Wed, Aug 12, 2009 at 12:17:07PM +0200, Ersue, Mehmet (NSN - DE/Munich) wrote: > NETCONF WG developed "capabilities" and introduced several of them. > Is it your proposal they shouldn't be used? I am wondering whether > we need a WG decision or BCP-like statement saying it shouldn't be > used. It would be interesting if you elaborate a bit why YANG > features should be used instead of NETCONF capabilities. (I know > some of the reasons but might be missing others. At the end we need > a record on the maillist if we want to push such a decision.) I believe we did not communicate this well... NETCONF provides a capability exchange mechanism which uses URIs to identify capabilities. The NETCONF protocol defines some core capability URIs but otherwise leaves the format of capability URIs pretty much open. YANG uses the NETCONF capability exchange and imposes a format on the URIs to communicate among other things data model defined features. The common format of the URIs allows to write generic code to analyse these URIs. So everything is actually pretty fine in the sense that NETCONF provides a mechanism and YANG uses and further restricts the mechanism in order to enhance interoperability. All we want to achieve is to do away with handcrafted URI formats (often miscommunicated as "avoid capabilities") and instead use the YANG feature mechanisms. The existing NETCONF URIs of course won't be changed - but for new URIs, we like to use the YANG format. Does this help? /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 Wed Aug 12 10:34: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 35F0D3A6B56; Wed, 12 Aug 2009 10:34:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.288 X-Spam-Level: X-Spam-Status: No, score=-3.288 tagged_above=-999 required=5 tests=[AWL=-0.689, 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 rbYSLY9n2vs2; Wed, 12 Aug 2009 10:34:23 -0700 (PDT) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [217.115.75.234]) by core3.amsl.com (Postfix) with ESMTP id 183853A6826; Wed, 12 Aug 2009 10:33:55 -0700 (PDT) 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 n7CH0o0W015356 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 12 Aug 2009 19:00:50 +0200 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 n7CH0oXF007945; Wed, 12 Aug 2009 19:00:50 +0200 Received: from DEMUEXC005.nsn-intra.net ([10.150.128.17]) by demuexc024.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 12 Aug 2009 19:00:50 +0200 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, 12 Aug 2009 19:00:50 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [netmod] staying in synch on data model discovery Thread-Index: AcobQKfrCo99F2pmQ+iCKvMBauxS3AACyEEAAAidEDA= From: "Ersue, Mehmet (NSN - DE/Munich)" To: "Juergen Schoenwaelder" X-OriginalArrivalTime: 12 Aug 2009 17:00:50.0628 (UTC) FILETIME=[71FDA040:01CA1B6E] Cc: netconf@ietf.org, netmod@ietf.org Subject: [Netconf] FW: [netmod] staying in synch on data model discovery 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, 12 Aug 2009 17:34:24 -0000 From: ext Juergen Schoenwaelder Wednesday, August 12, 2009 1:33 PM >=20 > On Wed, Aug 12, 2009 at 12:17:07PM +0200, Ersue, Mehmet (NSN=20 > - DE/Munich) wrote: > =20 > > NETCONF WG developed "capabilities" and introduced several of them. > > Is it your proposal they shouldn't be used? I am wondering whether > > we need a WG decision or BCP-like statement saying it shouldn't be > > used. It would be interesting if you elaborate a bit why YANG > > features should be used instead of NETCONF capabilities. (I know > > some of the reasons but might be missing others. At the end we need > > a record on the maillist if we want to push such a decision.) >=20 > I believe we did not communicate this well... >=20 > NETCONF provides a capability exchange mechanism which uses URIs to > identify capabilities. The NETCONF protocol defines some core > capability URIs but otherwise leaves the format of capability URIs > pretty much open. YANG uses the NETCONF capability exchange and > imposes a format on the URIs to communicate among other things data > model defined features. The common format of the URIs allows to write > generic code to analyse these URIs. So everything is actually pretty > fine in the sense that NETCONF provides a mechanism and YANG uses and > further restricts the mechanism in order to enhance interoperability. >=20 > All we want to achieve is to do away with handcrafted URI formats > (often miscommunicated as "avoid capabilities") and instead use the > YANG feature mechanisms. The existing NETCONF URIs of course won't be > changed - but for new URIs, we like to use the YANG format. Using NETCONF URIs in a specific way is fine from NETCONF POV. I support what has been proposed in Ch. 4.4. Conditional Statements=20 of the "YANG Usage guidelines" document. Mehmet =20 From j.schoenwaelder@jacobs-university.de Wed Aug 12 23:37:43 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 99D793A685E for ; Wed, 12 Aug 2009 23:37:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.17 X-Spam-Level: X-Spam-Status: No, score=-2.17 tagged_above=-999 required=5 tests=[AWL=0.079, 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 BYBnxVDNCmvV for ; Wed, 12 Aug 2009 23:37:42 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 913F23A6954 for ; Wed, 12 Aug 2009 23:37:42 -0700 (PDT) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id A5A86C007B for ; Thu, 13 Aug 2009 08:32:56 +0200 (CEST) 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 qneeQ7vgheQf; Thu, 13 Aug 2009 08:32:55 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id D23A7C000F; Thu, 13 Aug 2009 08:32:55 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 02177C65BC3; Thu, 13 Aug 2009 08:32:54 +0200 (CEST) Date: Thu, 13 Aug 2009 08:32:54 +0200 From: Juergen Schoenwaelder To: netconf@ietf.org Message-ID: <20090813063254.GA13273@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] netconf figure 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: Thu, 13 Aug 2009 06:37:43 -0000 Hi, the netconf figure in RFC 4741 is outdated. The YANG usage guidelines document contains a different figure: Layer Example +-------------+ +--------------------+ +-------------------+ (4) | Content | | Configuration data | | Notification data | +-------------+ +--------------------+ +-------------------+ | | | +-------------+ +-----------------+ +---------------+ (3) | Operations | | | | | +-------------+ +-----------------+ +---------------+ | | | +-------------+ +--------------------+ +----------------+ (2) | RPC | | , | | | +-------------+ +--------------------+ +----------------+ | | | +-------------+ +--------------------------------+ (1) | Transport | | BEEP, SSH, SSL, TLS, console | | Protocol | | | +-------------+ +--------------------------------+ I think this is better but still can be improved. First, there is no transport over SSL - there is only a transport over TLS. Second, there is a published transport over SOAP. Third, I think we should order the transports such that SSH (the mandatory to implement) comes first and I am not sure how useful console as a transport is. My preference would be to actually relabel the "Transport Protocol" layer to "Secure Transport" and the "RPC" layer to "Messages" layer. So what about this: Layer Example +-------------+ +--------------------+ +-------------------+ (4) | Content | | Configuration data | | Notification data | +-------------+ +--------------------+ +-------------------+ | | | +-------------+ +-----------------+ +---------------+ (3) | Operations | | | | | +-------------+ +-----------------+ +---------------+ | | | +-------------+ +--------------------+ +----------------+ (2) | Messages | | , | | | +-------------+ +--------------------+ +----------------+ | | | +-------------+ +--------------------------------+ (1) | Secure | | SSH, TLS, BEEP, SOAP, ... | | Transport | | | +-------------+ +--------------------------------+ Comments? I like to get the updated figure into 4741bis as the new authoritative source of it... /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From j.schoenwaelder@jacobs-university.de Thu Aug 13 02:27: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 E26D73A693F for ; Thu, 13 Aug 2009 02:27:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.174 X-Spam-Level: X-Spam-Status: No, score=-2.174 tagged_above=-999 required=5 tests=[AWL=0.075, 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 wdvuHBY60-HU for ; Thu, 13 Aug 2009 02:27:54 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 772D13A6A32 for ; Thu, 13 Aug 2009 02:27:52 -0700 (PDT) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 23D62C007C; Thu, 13 Aug 2009 11:25:47 +0200 (CEST) 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 KdSj2lh5qwqd; Thu, 13 Aug 2009 11:25:46 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 4ACC7C007A; Thu, 13 Aug 2009 11:25:46 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 66CE9C6626C; Thu, 13 Aug 2009 11:25:45 +0200 (CEST) Date: Thu, 13 Aug 2009 11:25:45 +0200 From: Juergen Schoenwaelder To: "Ersue, Mehmet (NSN - DE/Munich)" Message-ID: <20090813092545.GA14019@elstar.local> Mail-Followup-To: "Ersue, Mehmet (NSN - DE/Munich)" , "netconf@ietf.org" References: <20090813063254.GA13273@elstar.local> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.20 (2009-06-14) Cc: "netconf@ietf.org" Subject: Re: [Netconf] netconf figure 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: Thu, 13 Aug 2009 09:27:55 -0000 On Thu, Aug 13, 2009 at 10:57:21AM +0200, Ersue, Mehmet (NSN - DE/Munich) wrote: > > All is fine but SOAP is not a secure transport protocol. > s/SOAP/SOAP\/HTTPS/ > I expected this comment. But note this statement in section 4.2 of RFC 4743: At a miniumum, all conforming NETCONF over SOAP implementations MUST support TLS. Specifically, NETCONF over SOAP over HTTP MUST support NETCONF over SOAP over HTTPS, and NETCONF over SOAP over BEEP MUST support NETCONF over SOAP over BEEP over TLS. NETCONF does not have an architectural model but surely security services are expected to be provided by the "transport". This is also reflected in section 9 of RFC 4741: [...] It is anticipated that the underlying protocol (SSH, BEEP, etc) will provide for both confidentiality and authentication, as is required. I translate "underlying protocol" to the "transport" layer (1) (one more case where the usage of terms could be more precise). But yes, I do see your point that people will read "SOAP == secure" (but such a statement is naive by itself since even commonly assumed secure transports can usually be configured to run in plaintext mode). /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From j.schoenwaelder@jacobs-university.de Thu Aug 13 02:42: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 759543A692D for ; Thu, 13 Aug 2009 02:42:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.174 X-Spam-Level: X-Spam-Status: No, score=-2.174 tagged_above=-999 required=5 tests=[AWL=0.075, 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 mEEQNPM2FLdL for ; Thu, 13 Aug 2009 02:42:14 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 4AB5E3A680D for ; Thu, 13 Aug 2009 02:42:13 -0700 (PDT) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id EE02FC0082; Thu, 13 Aug 2009 11:31:46 +0200 (CEST) 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 WcVPV7rLO1BA; Thu, 13 Aug 2009 11:31:45 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id DCE91C0080; Thu, 13 Aug 2009 11:31:45 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id F3DA2C66323; Thu, 13 Aug 2009 11:31:44 +0200 (CEST) Date: Thu, 13 Aug 2009 11:31:44 +0200 From: Juergen Schoenwaelder To: "Ersue, Mehmet (NSN - DE/Munich)" Message-ID: <20090813093144.GA14045@elstar.local> Mail-Followup-To: "Ersue, Mehmet (NSN - DE/Munich)" , "netconf@ietf.org" References: <20090813063254.GA13273@elstar.local> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.20 (2009-06-14) Cc: "netconf@ietf.org" Subject: Re: [Netconf] netconf figure 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: Thu, 13 Aug 2009 09:42:15 -0000 On Thu, Aug 13, 2009 at 10:57:21AM +0200, Ersue, Mehmet (NSN - DE/Munich) wrote: > > All is fine but SOAP is not a secure transport protocol. > s/SOAP/SOAP\/HTTPS/ So what about this one: Layer Example +-------------+ +--------------------+ +-------------------+ (4) | Content | | Configuration data | | Notification data | +-------------+ +--------------------+ +-------------------+ | | | +-------------+ +-----------------+ +---------------+ (3) | Operations | | | | | +-------------+ +-----------------+ +---------------+ | | | +-------------+ +--------------------+ +----------------+ (2) | Messages | | , | | | +-------------+ +--------------------+ +----------------+ | | | +-------------+ +----------------------------------------+ (1) | Secure | | SSH, TLS, BEEP/TLS, SOAP/HTTP/TLS, ... | | Transports | | | +-------------+ +----------------------------------------+ /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 Thu Aug 13 02:56: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 0DE883A6811 for ; Thu, 13 Aug 2009 02:56:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.26 X-Spam-Level: X-Spam-Status: No, score=-3.26 tagged_above=-999 required=5 tests=[AWL=-0.661, 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 hxzlUPAqjQKB for ; Thu, 13 Aug 2009 02:56:54 -0700 (PDT) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [217.115.75.234]) by core3.amsl.com (Postfix) with ESMTP id C79F83A67AC for ; Thu, 13 Aug 2009 02:56:53 -0700 (PDT) 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 n7D8vN5v012892 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 13 Aug 2009 10:57:24 +0200 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 n7D8vLhY013709; Thu, 13 Aug 2009 10:57:23 +0200 Received: from DEMUEXC005.nsn-intra.net ([10.150.128.17]) by demuexc024.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Thu, 13 Aug 2009 10:57:23 +0200 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, 13 Aug 2009 10:57:21 +0200 Message-ID: In-Reply-To: <20090813063254.GA13273@elstar.local> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Netconf] netconf figure Thread-Index: Acob4JWlX4YYTf7SQ4C5BkSKjGXulgADnEpw References: <20090813063254.GA13273@elstar.local> From: "Ersue, Mehmet (NSN - DE/Munich)" To: "Juergen Schoenwaelder" , X-OriginalArrivalTime: 13 Aug 2009 08:57:23.0237 (UTC) FILETIME=[12A6C550:01CA1BF4] Subject: Re: [Netconf] netconf figure 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, 13 Aug 2009 09:56:55 -0000 All is fine but SOAP is not a secure transport protocol. s/SOAP/SOAP\/HTTPS/ Cheers, Mehmet =20 > -----Original Message----- > From: netconf-bounces@ietf.org=20 > [mailto:netconf-bounces@ietf.org] On Behalf Of ext Juergen=20 > Schoenwaelder > Sent: Thursday, August 13, 2009 8:33 AM > To: netconf@ietf.org > Subject: [Netconf] netconf figure >=20 > Hi, >=20 > the netconf figure in RFC 4741 is outdated. The YANG usage guidelines > document contains a different figure: >=20 > Layer Example > +-------------+ +--------------------+=20 > +-------------------+ > (4) | Content | | Configuration data | |=20 > Notification data | > +-------------+ +--------------------+=20 > +-------------------+ > | | | > +-------------+ +-----------------+ +---------------+ > (3) | Operations | | | | | > +-------------+ +-----------------+ +---------------+ > | | | > +-------------+ +--------------------+ +----------------+ > (2) | RPC | | , | | | > +-------------+ +--------------------+ +----------------+ > | | | > +-------------+ +--------------------------------+ > (1) | Transport | | BEEP, SSH, SSL, TLS, console | > | Protocol | | | > +-------------+ +--------------------------------+ >=20 > I think this is better but still can be improved. First, there is no > transport over SSL - there is only a transport over TLS. Second, there > is a published transport over SOAP. Third, I think we should order the > transports such that SSH (the mandatory to implement) comes first and > I am not sure how useful console as a transport is. My preference > would be to actually relabel the "Transport Protocol" layer to "Secure > Transport" and the "RPC" layer to "Messages" layer. So what about > this: >=20 > Layer Example > +-------------+ +--------------------+=20 > +-------------------+ > (4) | Content | | Configuration data | |=20 > Notification data | > +-------------+ +--------------------+=20 > +-------------------+ > | | | > +-------------+ +-----------------+ +---------------+ > (3) | Operations | | | | | > +-------------+ +-----------------+ +---------------+ > | | | > +-------------+ +--------------------+ +----------------+ > (2) | Messages | | , | | | > +-------------+ +--------------------+ +----------------+ > | | | > +-------------+ +--------------------------------+ > (1) | Secure | | SSH, TLS, BEEP, SOAP, ... | > | Transport | | | > +-------------+ +--------------------------------+ >=20 > Comments? I like to get the updated figure into 4741bis as the new > authoritative source of it... >=20 > /js >=20 > --=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 >=20 From Tomasz.Mikolajczyk@s3group.com Thu Aug 13 04:27: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 6F2523A6A76 for ; Thu, 13 Aug 2009 04:27:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.089 X-Spam-Level: * X-Spam-Status: No, score=1.089 tagged_above=-999 required=5 tests=[AWL=0.604, BAYES_00=-2.599, HELO_EQ_PL=1.135, HOST_EQ_PL=1.95] 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 Zp-kVopaAyD8 for ; Thu, 13 Aug 2009 04:27:05 -0700 (PDT) Received: from ormo.s3group.com.pl (ormo.s3group.com.pl [212.160.116.194]) by core3.amsl.com (Postfix) with ESMTP id 653B23A69DF for ; Thu, 13 Aug 2009 04:27:04 -0700 (PDT) Received: from exwro.wroclaw.ad.s3group.com (exwro.wroclaw.s3group.com [192.168.88.33]) by ormo.s3group.com.pl with ESMTP id n7D9kjPf006585; Thu, 13 Aug 2009 11:46:45 +0200 Received: from [192.168.88.87] ([192.168.88.87]) by exwro.wroclaw.ad.s3group.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 13 Aug 2009 11:46:45 +0200 Message-ID: <4A83E105.1040305@s3group.com> Date: Thu, 13 Aug 2009 11:46:45 +0200 From: Tomasz Mikolajczyk Organization: Silicon & Software Systems User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) MIME-Version: 1.0 To: Wes Hardaker References: <20090804095639.GA21611@elstar.local> <4A784734.7080201@netconfcentral.com> <20090804144838.GA962@elstar.local> <4A784E8E.8000007@netconfcentral.com> <20090804184136.GC1038@elstar.local> <4A788A66.4030106@bwijnen.net> <20090804211449.GA1307@elstar.local> <4A78AA22.4070405@netconfcentral.com> <4A79873D.1030007@netconfcentral.com> <20090805143434.GB2612@elstar.local> <4A799E9D.4050605@s3group.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 13 Aug 2009 09:46:45.0196 (UTC) FILETIME=[F81DD8C0:01CA1BFA] X-Scanner: InterScan AntiVirus for Sendmail X-Filter-Version: 1.11,S3-1.6 (ormo.s3group.com.pl) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.0 (ormo.s3group.com.pl [212.160.116.194]); Thu, 13 Aug 2009 11:46:48 +0200 (CEST) Cc: Netconf Subject: Re: [Netconf] Fw: Database Architecture OK or NOT-OK? 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, 13 Aug 2009 11:27:06 -0000 Hi, Wes Hardaker wrote: > The discussion, reading it a bit late, sure makes it look like a > netconf-bis that completely replaces the original would be a good thing > at this point. +1 Starting from the scratch would be the best IMHO. New features are being added to the protocol, while the concept doesn't stand the pressure. Regards, Tomasz Mikolajczyk The information contained in this e-mail and in any attachments is confidential and is designated solely for the attention of the intended recipient(s). If you are not an intended recipient, you must not use, disclose, copy, distribute or retain this e-mail or any part thereof. If you have received this e-mail in error, please notify the sender by return e-mail and delete all copies of this e-mail from your computer system(s). Please direct any additional queries to: communications@s3group.com. Thank You. Silicon and Software Systems Limited. Registered in Ireland no. 378073. Registered Office: South County Business Park, Leopardstown, Dublin 18 From andy@netconfcentral.com Thu Aug 13 07:36: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 3B1DB3A6A33 for ; Thu, 13 Aug 2009 07:36:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.475 X-Spam-Level: X-Spam-Status: No, score=-2.475 tagged_above=-999 required=5 tests=[AWL=0.124, 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 S5TqISfXVSk8 for ; Thu, 13 Aug 2009 07:36:14 -0700 (PDT) Received: from smtp107.sbc.mail.mud.yahoo.com (smtp107.sbc.mail.mud.yahoo.com [68.142.198.206]) by core3.amsl.com (Postfix) with SMTP id 631C83A68B8 for ; Thu, 13 Aug 2009 07:36:14 -0700 (PDT) Received: (qmail 54216 invoked from network); 13 Aug 2009 14:33:27 -0000 Received: from unknown (HELO ?192.168.0.10?) (andy@67.125.157.61 with plain) by smtp107.sbc.mail.mud.yahoo.com with SMTP; 13 Aug 2009 14:33:27 -0000 X-YMail-OSG: 0X7xze4VM1kX2q7SHsHCxEnoHKixWyIdy7oymMdQMnXnjaOdvg7G6GzSPDEJ07QosO1rwiaSK3kZ_WmanBmAWdws2qZTJ9DZjG8z7CqilzQTHmV6Fs.AMm2M_3Xpij7.6X5dtYN5ilwxRT0MCiIiOtJu_jx.1oUgc_w_hNubZOsStU7R7wtEd3I9GG_wGec_RVmlWhpafaayKgUuqagtzM1BuMIwhjtm7gOq7MOkS8WSyFBWIghWmorDQbyr3435W7Mqdf3g8JPZsBo- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4A842497.7010508@netconfcentral.com> Date: Thu, 13 Aug 2009 07:35:03 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.22 (X11/20090608) MIME-Version: 1.0 To: Tomasz Mikolajczyk References: <20090804095639.GA21611@elstar.local> <4A784734.7080201@netconfcentral.com> <20090804144838.GA962@elstar.local> <4A784E8E.8000007@netconfcentral.com> <20090804184136.GC1038@elstar.local> <4A788A66.4030106@bwijnen.net> <20090804211449.GA1307@elstar.local> <4A78AA22.4070405@netconfcentral.com> <4A79873D.1030007@netconfcentral.com> <20090805143434.GB2612@elstar.local> <4A799E9D.4050605@s3group.com> <4A83E105.1040305@s3group.com> In-Reply-To: <4A83E105.1040305@s3group.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Netconf Subject: Re: [Netconf] Fw: Database Architecture OK or NOT-OK? 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, 13 Aug 2009 14:36:15 -0000 Tomasz Mikolajczyk wrote: > Hi, > > Wes Hardaker wrote: > >> The discussion, reading it a bit late, sure makes it look like a >> netconf-bis that completely replaces the original would be a good thing >> at this point. > > +1 > Starting from the scratch would be the best IMHO. New features are being > added to the protocol, while the concept doesn't stand the pressure. > This is a fairly content-free comment. While I do not think partial-locking applies to any database but , I do not agree that the whole protocol needs to be scrapped. My comment about protocol versions was about too many little optional features. It would require a new protocol version number to change optional bits to mandatory. I pointed out 6 years ago that optional 'manual' database locking was a really stupid choice. Others also tried to steer NETCONF towards a ... model, but some people insisted that database locking should be optional to use. Some people insist that informing every possible database user by email to stay out of the candidate config for awhile is some form of locking. They call it "cooperative locking". Why would starting over produce a better design outcome this time? What evidence is there that the NETCONF WG has any competence in this area at all? IMO, this major disruption in the standard will not yield any better results -- it will just waste time. > Regards, > Tomasz Mikolajczyk Andy From mehmet.ersue@nsn.com Thu Aug 13 09:28: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 4DCAF3A6B9D for ; Thu, 13 Aug 2009 09:28:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.235 X-Spam-Level: X-Spam-Status: No, score=-3.235 tagged_above=-999 required=5 tests=[AWL=-0.636, 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 1zVAvuYE-0EM for ; Thu, 13 Aug 2009 09:28:05 -0700 (PDT) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [217.115.75.234]) by core3.amsl.com (Postfix) with ESMTP id 4550B3A6882 for ; Thu, 13 Aug 2009 09:28:04 -0700 (PDT) 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 n7DGPtnK018661 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 13 Aug 2009 18:25:55 +0200 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 n7DGPs9U009837; Thu, 13 Aug 2009 18:25:54 +0200 Received: from DEMUEXC005.nsn-intra.net ([10.150.128.17]) by demuexc022.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Thu, 13 Aug 2009 18:25:54 +0200 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, 13 Aug 2009 18:25:53 +0200 Message-ID: In-Reply-To: <20090813093144.GA14045@elstar.local> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Netconf] netconf figure Thread-Index: Acob+OSYwxA/KW++Tmidp5R8VTEbZQANu2xg References: <20090813063254.GA13273@elstar.local> <20090813093144.GA14045@elstar.local> From: "Ersue, Mehmet (NSN - DE/Munich)" To: X-OriginalArrivalTime: 13 Aug 2009 16:25:54.0839 (UTC) FILETIME=[BB375A70:01CA1C32] Subject: Re: [Netconf] netconf figure 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, 13 Aug 2009 16:28:06 -0000 After a short offline discussion we agree that... It is good to highlight that we have "Secure Transports" and it would the best to have "SSH, TLS, BEEP, SOAP/HTTPS" on layer (1) of the picture. It would be appropriate if people use BEEP and SOAP on top of TLS but it is not prohibited to use BEEP with SASL nor 'SOAP over HTTP over SSL'. BTW: SASL supports secure transport so you don't have to have TLS with BEEP if you use SASL. There is a value in using TLS instead of SASL or SSL but it is the job of the transport mappings to recommend TLS. The core NETCONF document should not really go into those details.=20 Cheers, Mehmet =20 > -----Original Message----- > From: ext Juergen Schoenwaelder=20 > [mailto:j.schoenwaelder@jacobs-university.de]=20 > Sent: Thursday, August 13, 2009 11:32 AM > To: Ersue, Mehmet (NSN - DE/Munich) > Cc: netconf@ietf.org > Subject: Re: [Netconf] netconf figure >=20 > On Thu, Aug 13, 2009 at 10:57:21AM +0200, Ersue, Mehmet (NSN=20 > - DE/Munich) wrote: > >=20 > > All is fine but SOAP is not a secure transport protocol. > > s/SOAP/SOAP\/HTTPS/ >=20 > So what about this one: >=20 > Layer Example > +-------------+ +--------------------+ +-------------------+ > (4) | Content | | Configuration data | | Notification data | > +-------------+ +--------------------+ +-------------------+ > | | | > +-------------+ +-----------------+ +---------------+ > (3) | Operations | | | | | > +-------------+ +-----------------+ +---------------+ > | | | > +-------------+ +--------------------+ +----------------+ > (2) | Messages | | , | | | > +-------------+ +--------------------+ +----------------+ > | | | > +-------------+ +----------------------------------------+ > (1) | Secure | | SSH, TLS, BEEP/TLS, SOAP/HTTP/TLS, ... | > | Transports | | | > +-------------+ +----------------------------------------+ >=20 > /js=20 >=20 > --=20 > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany > Fax: +49 421 200 3103 >=20 From phil@juniper.net Thu Aug 13 09:33:43 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 664A73A6B9A for ; Thu, 13 Aug 2009 09:33:43 -0700 (PDT) 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 Hx4LYxecbJb4 for ; Thu, 13 Aug 2009 09:33:42 -0700 (PDT) Received: from exprod7og118.obsmtp.com (exprod7og118.obsmtp.com [64.18.2.8]) by core3.amsl.com (Postfix) with ESMTP id 8F73F3A6945 for ; Thu, 13 Aug 2009 09:33:42 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob118.postini.com ([64.18.6.12]) with SMTP ID DSNKSoQ/6cAsJfvtrM0ej2tn8T/fiT3meqnP@postini.com; Thu, 13 Aug 2009 09:33:47 PDT 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, 13 Aug 2009 09:21:49 -0700 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, 13 Aug 2009 09:21:50 -0700 Received: from emailsmtp56.jnpr.net ([172.24.60.77]) by p-emlb02-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Thu, 13 Aug 2009 09:21:48 -0700 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp56.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Thu, 13 Aug 2009 09:21:48 -0700 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 n7DGLld30369; Thu, 13 Aug 2009 09:21:48 -0700 (PDT) (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 n7DGA3Cr092752; Thu, 13 Aug 2009 16:10:03 GMT (envelope-from phil@idle.juniper.net) Message-ID: <200908131610.n7DGA3Cr092752@idle.juniper.net> To: Juergen Schoenwaelder In-Reply-To: <20090813063254.GA13273@elstar.local> Date: Thu, 13 Aug 2009 12:10:03 -0400 From: Phil Shafer X-OriginalArrivalTime: 13 Aug 2009 16:21:48.0479 (UTC) FILETIME=[285FCCF0:01CA1C32] MIME-Version: 1.0 Content-Type: text/plain Cc: netconf@ietf.org Subject: Re: [Netconf] netconf figure 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, 13 Aug 2009 16:33:43 -0000 Juergen Schoenwaelder writes: > +-------------+ +-----------------+ +---------------+ > (3) | Operations | | | | | > +-------------+ +-----------------+ +---------------+ Is "eventType" an operation? Thanks, Phil From phil@juniper.net Thu Aug 13 09:39: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 6B1443A6AA4 for ; Thu, 13 Aug 2009 09:39:26 -0700 (PDT) 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 sGory2NUwW49 for ; Thu, 13 Aug 2009 09:39:25 -0700 (PDT) Received: from exprod7og116.obsmtp.com (exprod7og116.obsmtp.com [64.18.2.219]) by core3.amsl.com (Postfix) with ESMTP id 9FF773A68CF for ; Thu, 13 Aug 2009 09:39:03 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob116.postini.com ([64.18.6.12]) with SMTP ID DSNKSoRBPldfpV9OsOlzTfVAl/DVDHcbDdBO@postini.com; Thu, 13 Aug 2009 09:39:09 PDT 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, 13 Aug 2009 09:27:49 -0700 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, 13 Aug 2009 09:27:49 -0700 Received: from emailsmtp56.jnpr.net ([172.24.60.77]) by p-emlb01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Thu, 13 Aug 2009 09:27:49 -0700 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp56.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Thu, 13 Aug 2009 09:27:48 -0700 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 n7DGRld33260; Thu, 13 Aug 2009 09:27:47 -0700 (PDT) (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 n7DGG2Ol092801; Thu, 13 Aug 2009 16:16:02 GMT (envelope-from phil@idle.juniper.net) Message-ID: <200908131616.n7DGG2Ol092801@idle.juniper.net> To: Andy Bierman In-Reply-To: <4A842497.7010508@netconfcentral.com> Date: Thu, 13 Aug 2009 12:16:02 -0400 From: Phil Shafer X-OriginalArrivalTime: 13 Aug 2009 16:27:48.0140 (UTC) FILETIME=[FEBFB6C0:01CA1C32] MIME-Version: 1.0 Content-Type: text/plain Cc: Netconf Subject: Re: [Netconf] Fw: Database Architecture OK or NOT-OK? 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, 13 Aug 2009 16:39:26 -0000 Andy Bierman writes: >Some people insist that informing every possible database user by email >to stay out of the candidate config for awhile is some form >of locking. They call it "cooperative locking". I don't recall this point or these people. Do you have a reference? Thanks, Phil From andy@netconfcentral.com Thu Aug 13 10:26: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 09A973A693C for ; Thu, 13 Aug 2009 10:26:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.476 X-Spam-Level: X-Spam-Status: No, score=-2.476 tagged_above=-999 required=5 tests=[AWL=0.123, 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 cyL4DjasFemc for ; Thu, 13 Aug 2009 10:26:35 -0700 (PDT) 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 4DCD03A69E9 for ; Thu, 13 Aug 2009 10:26:35 -0700 (PDT) Received: (qmail 91321 invoked from network); 13 Aug 2009 17:25:50 -0000 Received: from unknown (HELO ?192.168.0.10?) (andy@67.125.157.61 with plain) by smtp103.sbc.mail.mud.yahoo.com with SMTP; 13 Aug 2009 17:25:50 -0000 X-YMail-OSG: OsKcF9EVM1m3WqzmVT2wq58hEyiB7aoBT5.5oprgH_BOMM4ykjTUPgGyDQdV7gly_mwyxr92Exoky9CIJSKRWTAXgta2kJtEFpTXXl.wo8rByIvuXnUhN_ig2nK_yVnWu3mVvVftkYSrAdJqJ37NUolW_AbAYy9qDLOvPo9u1DPsNZxy3YY3NWg4lS.8tfef7UW2TAUO2m_sNzz7i.3TwF0r2QUCaIy6aNRe_F5idzPZix10P6d0F_rrHIdq8yDEnzf0ny7KYDenYZ8- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4A844CFE.1020601@netconfcentral.com> Date: Thu, 13 Aug 2009 10:27:26 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.22 (X11/20090608) MIME-Version: 1.0 To: Phil Shafer References: <200908131616.n7DGG2Ol092801@idle.juniper.net> In-Reply-To: <200908131616.n7DGG2Ol092801@idle.juniper.net> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Netconf Subject: Re: [Netconf] Fw: Database Architecture OK or NOT-OK? 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, 13 Aug 2009 17:26:36 -0000 Phil Shafer wrote: > Andy Bierman writes: >> Some people insist that informing every possible database user by email >> to stay out of the candidate config for awhile is some form >> of locking. They call it "cooperative locking". > > I don't recall this point or these people. Do you have a reference? > 2.1.1.3. Multiple managers handling the candidate datastore in a semi- coordinated work mode Sorry, it is called 'semi-coordinated', not 'cooperative'. My mistake. > Thanks, > Phil > Andy From j.schoenwaelder@jacobs-university.de Thu Aug 13 10:26: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 8843528C15B for ; Thu, 13 Aug 2009 10:26:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.18 X-Spam-Level: X-Spam-Status: No, score=-2.18 tagged_above=-999 required=5 tests=[AWL=0.069, 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 wTzy+HGKszaN for ; Thu, 13 Aug 2009 10:26:56 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id BC3DF3A6C3A for ; Thu, 13 Aug 2009 10:26:56 -0700 (PDT) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 2F150C00BB; Thu, 13 Aug 2009 19:26:18 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius4.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id tbZjeb3TNY4O; Thu, 13 Aug 2009 19:26:17 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 6A4F1C00B9; Thu, 13 Aug 2009 19:26:16 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 8D2BAC66E65; Thu, 13 Aug 2009 19:26:15 +0200 (CEST) Date: Thu, 13 Aug 2009 19:26:15 +0200 From: Juergen Schoenwaelder To: Phil Shafer Message-ID: <20090813172615.GA15494@elstar.local> Mail-Followup-To: Phil Shafer , "netconf@ietf.org" References: <20090813063254.GA13273@elstar.local> <200908131610.n7DGA3Cr092752@idle.juniper.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200908131610.n7DGA3Cr092752@idle.juniper.net> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: "netconf@ietf.org" Subject: Re: [Netconf] netconf figure 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: Thu, 13 Aug 2009 17:26:57 -0000 On Thu, Aug 13, 2009 at 06:10:03PM +0200, Phil Shafer wrote: > Juergen Schoenwaelder writes: > > +-------------+ +-----------------+ +---------------+ > > (3) | Operations | | | | | > > +-------------+ +-----------------+ +---------------+ > > Is "eventType" an operation? As the caml-case already indicates, it is an accident. ;-) If you color the boxes covered by YANG, you also see some interesting assymmetry centered around . Perhaps we should simply remove this box from the figure... /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 Fri Aug 14 02:11: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 636753A67C0 for ; Fri, 14 Aug 2009 02:11:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.211 X-Spam-Level: X-Spam-Status: No, score=-3.211 tagged_above=-999 required=5 tests=[AWL=-0.613, 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 2VRZi1+yEgy1 for ; Fri, 14 Aug 2009 02:11:47 -0700 (PDT) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [217.115.75.234]) by core3.amsl.com (Postfix) with ESMTP id 422483A67B4 for ; Fri, 14 Aug 2009 02:11:46 -0700 (PDT) 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 n7E8oIel006858 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 14 Aug 2009 10:50:18 +0200 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 n7E8oFJ7026332; Fri, 14 Aug 2009 10:50:18 +0200 Received: from DEMUEXC005.nsn-intra.net ([10.150.128.17]) by demuexc024.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Fri, 14 Aug 2009 10:50:17 +0200 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_01CA1CBC.3F1BF9E3" Date: Fri, 14 Aug 2009 10:50:16 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Minutes of the IETF #75 NETCONF session Thread-Index: AcocvD7b+tc6F/vPQMq5zN395Ceplg== From: "Ersue, Mehmet (NSN - DE/Munich)" To: X-OriginalArrivalTime: 14 Aug 2009 08:50:17.0939 (UTC) FILETIME=[3F913230:01CA1CBC] Subject: [Netconf] Minutes of the IETF #75 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: Fri, 14 Aug 2009 09:11:48 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CA1CBC.3F1BF9E3 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dear All, please find the uploaded minutes at: http://www.ietf.org/proceedings/75/minutes/netconf.txt Cheers, Mehmet From: netconf-bounces@ietf.org [mailto:netconf-bounces@ietf.org] On Behalf Of ext Ersue, Mehmet (NSN - DE/Munich) Sent: Thursday, August 06, 2009 10:47 PM To: netconf@ietf.org Subject: [Netconf] Draft minutes for IETF #75 NETCONF session Dear NETCONF WG,=20 attached are the draft minutes for the NETCONF session=20 at IETF #75.=20 Many thanks to Lada and Juergen for taking the minutes=20 and David P for scribing and channeling the jabber room!=20 Please review the minutes and let us know your change=20 requests or comments by August 12, 2009 EOB. Thanks.=20 <>=20 Mehmet & Bert=20 ------_=_NextPart_001_01CA1CBC.3F1BF9E3 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Minutes of the IETF #75 NETCONF session

Dear All,

please find the uploaded minutes = at:
http://www.ietf.org/proceedings/75/minutes/netconf.txt

Cheers,
Mehmet

From: netconf-bounces@ietf.org [mailto:netconf-bounces@ietf.org] On = Behalf Of ext Ersue, Mehmet = (NSN - DE/Munich)
Sent: Thursday, August 06, 2009 10:47 PM
To: netconf@ietf.org
Subject: [Netconf] Draft minutes for IETF #75 NETCONF = session
Dear NETCONF WG,
attached are the draft minutes for = the NETCONF session
at IETF #75.
Many thanks to Lada and Juergen for = taking the minutes
and David P for scribing and channeling = the jabber room!
Please review the minutes and let us = know your change
requests or comments by August 12, 2009 = EOB. Thanks.
<<Draft_IETF = 75_NETCONF Minutes.txt>>
Mehmet & Bert

------_=_NextPart_001_01CA1CBC.3F1BF9E3-- From mbj@tail-f.com Tue Aug 18 00:22:43 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 89AEA3A6B42 for ; Tue, 18 Aug 2009 00:22:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.348 X-Spam-Level: X-Spam-Status: No, score=-1.348 tagged_above=-999 required=5 tests=[AWL=-0.502, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_27=0.6, J_CHICKENPOX_29=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 l1FN-Uy4FhuC for ; Tue, 18 Aug 2009 00:22:42 -0700 (PDT) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id 84C6A3A6B2C for ; Tue, 18 Aug 2009 00:22:42 -0700 (PDT) Received: from localhost (138.162.241.83.in-addr.dgcsystems.net [83.241.162.138]) by mail.tail-f.com (Postfix) with ESMTPSA id 90053616017 for ; Tue, 18 Aug 2009 09:21:30 +0200 (CEST) Date: Tue, 18 Aug 2009 09:21:30 +0200 (CEST) Message-Id: <20090818.092130.237312565.mbj@tail-f.com> To: netconf@ietf.org From: Martin Bjorklund In-Reply-To: <4A7984EA.4000703@ericsson.com> References: <4A7984EA.4000703@ericsson.com> X-Mailer: Mew version 6.0.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] [Fwd: New Version Notification for draft-ietf-netconf-with-defaults-03] 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, 18 Aug 2009 07:22:43 -0000 Hi, Here are my comments on with-defaults-03. General: --------- I have implemented a proprietary version of this capability, and plan to move to this version when it is finished. I agree with previous comments that this draft should move along with 4741bis, so that the XSD can be removed and YANG be normative. One reason is that the XSD together with the XSD in 4741 cannot be used to validate the PDUs (b/c of the extensibility problem of the XSD in 4741). Abstract: --------- s/NETCONF manger/NETCONF client/ Section 1 --------- Talks about default valus being part of . But this isn't the whole story, since it also can be controlled for copy-config result (url). 2.1 --- s/A NETCONF servers/A NETCONF server/ 2.3 --- s/This indicates what other default handling modes does the server support./This parameter indicates which additional default handling modes the server supports./ 2.5 --- "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 ." I think this can be made more specific, e.g. A new parameter "with-defaults" is added to the , , and operations. "If the target is a NETCONF datastore (running, candidate or startup) the capability has no effect." So if the capability has no effect, what happens if the with-defaults parameter is present? Will you get an error (which one?) or is the parameter silently ignored? Section 4 --------- As I said I prefer the XSD to be removed, but it also contains an error; it defines an xs:attribute, it should be an xs:element. Section 5 --------- "Network Configuration Protocol (NETCONF) Capability URNs" Is this the registry "netconf", defined in 4741? I suggest you also add a reference to 4741 here. Section 6 --------- s/operations. it does/operations. It does/ s/provides client controls/gives the client control/ ?? Section 7 --------- Remove this section. Section 8 --------- s;// for the uri data type;; why is with-default defined as a feature? /martin From shikhar@schmizz.net Wed Aug 19 15:01: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 14C0E3A6FBE for ; Wed, 19 Aug 2009 15:01:47 -0700 (PDT) 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=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] 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 uVAOWyL5q1ll for ; Wed, 19 Aug 2009 15:01:46 -0700 (PDT) Received: from mail-px0-f171.google.com (mail-px0-f171.google.com [209.85.216.171]) by core3.amsl.com (Postfix) with ESMTP id 7914F3A6CFC for ; Wed, 19 Aug 2009 15:01:46 -0700 (PDT) Received: by pxi1 with SMTP id 1so3075034pxi.31 for ; Wed, 19 Aug 2009 15:01:49 -0700 (PDT) MIME-Version: 1.0 Received: by 10.115.100.23 with SMTP id c23mr8134468wam.9.1250719307988; Wed, 19 Aug 2009 15:01:47 -0700 (PDT) In-Reply-To: <20090813063254.GA13273@elstar.local> References: <20090813063254.GA13273@elstar.local> Date: Thu, 20 Aug 2009 00:01:47 +0200 Message-ID: <309bec650908191501qa3a94fk1dc9db4d555599fc@mail.gmail.com> From: shikhar To: Juergen Schoenwaelder , netconf@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [Netconf] netconf figure 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, 19 Aug 2009 22:01:47 -0000 On Thu, Aug 13, 2009 at 8:32 AM, Juergen Schoenwaelder wrote: > My preference > would be to actually relabel the "Transport Protocol" layer to "Secure > Transport" and the "RPC" layer to "Messages" layer. A move to "Messages" instead of "RPC" would definitely be good in light of 's and any future extensions. Shikhar From lhotka@cesnet.cz Thu Aug 20 02:30: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 4FB6A28C0EF for ; Thu, 20 Aug 2009 02:30:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.209 X-Spam-Level: X-Spam-Status: No, score=-1.209 tagged_above=-999 required=5 tests=[AWL=0.041, 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 KbjFXT1OG6-Z for ; Thu, 20 Aug 2009 02:30:47 -0700 (PDT) Received: from office2.cesnet.cz (office2.cesnet.cz [195.113.144.244]) by core3.amsl.com (Postfix) with ESMTP id 7DC343A6BB6 for ; Thu, 20 Aug 2009 02:30:47 -0700 (PDT) Received: from [172.29.2.201] (asus-gx.lhotka.cesnet.cz [195.113.161.161]) by office2.cesnet.cz (Postfix) with ESMTP id 65608D800C1 for ; Thu, 20 Aug 2009 11:30:52 +0200 (CEST) From: Ladislav Lhotka To: NETCONF WG Content-Type: text/plain Organization: CESNET Date: Thu, 20 Aug 2009 11:30:50 +0200 Message-Id: <1250760650.23073.3.camel@missotis> Mime-Version: 1.0 X-Mailer: Evolution 2.26.1 Content-Transfer-Encoding: 7bit Subject: [Netconf] review of draft-ietf-netconf-with-defaults-03 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, 20 Aug 2009 09:30:48 -0000 Hi, below are my comments to the draft. Lada ==================================================================== General notes ------------- The draft does a good job in explaining the existing approaches to defaults handling and provides a general framework that can be used with any of the approaches. Because of the chicken-and-egg problem, the draft also deliberately avoids any reference to YANG, and vice versa. However, since the consensus is (and I support it) to use the YANG module from Appendix A as normative instead of XSD, a section on interactions between YANG and :with-defaults capability seems appropriate and useful. In particular, the role of the 'default' statement should be explained, if there is any. Section 1 --------- s/theses cases/these cases/ Section 1.2 --------- The "explicit" strategy needs more explanation, "explicitly set" can mean different things: - explicitly set within the same NETCONF session, or - within any NETCONF session, or - also by other methods (CLI, internal server scripts etc.). Section 2.5 ----------- The namespace URI for element should be specified in the main text. -- Ladislav Lhotka, CESNET PGP Key ID: E74E8C0C From dbharrington@comcast.net Tue Aug 25 05: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 8E3383A6B56 for ; Tue, 25 Aug 2009 05:47:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.11 X-Spam-Level: X-Spam-Status: No, score=-1.11 tagged_above=-999 required=5 tests=[BAYES_05=-1.11] 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 A6LGVbx-5brj for ; Tue, 25 Aug 2009 05:47:47 -0700 (PDT) Received: from QMTA03.westchester.pa.mail.comcast.net (qmta03.westchester.pa.mail.comcast.net [76.96.62.32]) by core3.amsl.com (Postfix) with ESMTP id 634043A6B9D for ; Tue, 25 Aug 2009 05:47:46 -0700 (PDT) Received: from OMTA09.westchester.pa.mail.comcast.net ([76.96.62.20]) by QMTA03.westchester.pa.mail.comcast.net with comcast id Yban1c0050SCNGk53cnFKo; Tue, 25 Aug 2009 12:47:15 +0000 Received: from Harrington73653 ([24.147.240.21]) by OMTA09.westchester.pa.mail.comcast.net with comcast id Ycnt1c00A0UQ6dC3VcntHY; Tue, 25 Aug 2009 12:47:54 +0000 From: "David B Harrington" To: "'Juergen Schoenwaelder'" , "'Ersue, Mehmet \(NSN - DE/Munich\)'" References: <20090813063254.GA13273@elstar.local> <20090813093144.GA14045@elstar.local> Date: Tue, 25 Aug 2009 08:47:52 -0400 Message-ID: <032901ca2582$42c98640$0600a8c0@china.huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <20090813093144.GA14045@elstar.local> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Thread-Index: Acob+l44vhN7q+XkR3K5888Rvm7OGAJhQf8Q Cc: netconf@ietf.org Subject: Re: [Netconf] netconf figure 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, 25 Aug 2009 12:47:48 -0000 Hi, I support this change. I wish this was the layering used when SNMPv3 was designed; it would have made adding extensions to SNMPv3 simpler. Where do you envision data access controls in this layering? dbh > -----Original Message----- > From: netconf-bounces@ietf.org > [mailto:netconf-bounces@ietf.org] On Behalf Of Juergen Schoenwaelder > Sent: Thursday, August 13, 2009 5:32 AM > To: Ersue, Mehmet (NSN - DE/Munich) > Cc: netconf@ietf.org > Subject: Re: [Netconf] netconf figure > > On Thu, Aug 13, 2009 at 10:57:21AM +0200, Ersue, Mehmet (NSN > - DE/Munich) wrote: > > > > All is fine but SOAP is not a secure transport protocol. > > s/SOAP/SOAP\/HTTPS/ > > So what about this one: > > Layer Example > +-------------+ +--------------------+ +-------------------+ > (4) | Content | | Configuration data | | Notification data | > +-------------+ +--------------------+ +-------------------+ > | | | > +-------------+ +-----------------+ +---------------+ > (3) | Operations | | | | | > +-------------+ +-----------------+ +---------------+ > | | | > +-------------+ +--------------------+ +----------------+ > (2) | Messages | | , | | | > +-------------+ +--------------------+ +----------------+ > | | | > +-------------+ +----------------------------------------+ > (1) | Secure | | SSH, TLS, BEEP/TLS, SOAP/HTTP/TLS, ... | > | Transports | | | > +-------------+ +----------------------------------------+ > > /js > > -- > 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 ietfdbh@comcast.net Tue Aug 25 06:51:44 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 96F1C3A6AEB for ; Tue, 25 Aug 2009 06:51:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.914 X-Spam-Level: X-Spam-Status: No, score=-1.914 tagged_above=-999 required=5 tests=[AWL=0.685, 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 MXh-8DNGJwwo for ; Tue, 25 Aug 2009 06:51:43 -0700 (PDT) Received: from QMTA13.westchester.pa.mail.comcast.net (qmta13.westchester.pa.mail.comcast.net [76.96.59.243]) by core3.amsl.com (Postfix) with ESMTP id EE5D33A6BD9 for ; Tue, 25 Aug 2009 06:51:42 -0700 (PDT) Received: from OMTA13.westchester.pa.mail.comcast.net ([76.96.62.52]) by QMTA13.westchester.pa.mail.comcast.net with comcast id Yb1g1c00N17dt5G5DdrqrH; Tue, 25 Aug 2009 13:51:50 +0000 Received: from Harrington73653 ([24.147.240.21]) by OMTA13.westchester.pa.mail.comcast.net with comcast id Ydrp1c00E0UQ6dC3Zdrpu6; Tue, 25 Aug 2009 13:51:50 +0000 From: "David Harrington" To: "'Juergen Schoenwaelder'" , "'Phil Shafer'" References: <4A7F20EB.2010002@netconfcentral.com><200908101321.n7ADLxqS058788@idle.juniper.net> <20090811142514.GB1042@elstar.local> Date: Tue, 25 Aug 2009 09:51:48 -0400 Message-ID: <032d01ca258b$31407470$0600a8c0@china.huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <20090811142514.GB1042@elstar.local> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Thread-Index: Acoaj+BYkPR1AVRaQb2L605mv68AWwK9XyNw Cc: netconf@ietf.org Subject: Re: [Netconf] Comments on draft-ietf-netconf-monitoring-06.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: Tue, 25 Aug 2009 13:51:44 -0000 Hi, I recommend against a hierarchy based on IETF area. Operators don't care about IETF areas; they care about protocols and functionality. should we learn from experience? IANA already defines a hierarchy for NM information: MIBs are organized into internet/mgmt/mib-2 (ietf mib modules) internet/experimental internet/private/enterprise we might want /ietf /experimental /enterprise / we learned that having an snmpv2-specific subtree didn't help much, but serves to provide a common registration point for things like snmp domains, proxies, and modules. We might want a /netconf subtree for registering netconf-specific things, such as capabilities, but that should work just as well in an ietf subtree /ietf/netconf we learned that some things that need easy registration changes, such as ifTypes, should be handled by IANA directly, so maybe we want to define an /iana subtree. we learned that allowing WGs (e.g., RMON and MPLS) to define their own sub-trees became problematic. The preferred hierarchy now is to use a relatively flat approach, with most mib modules being registered directly under mib-2. Bert and Dan can talk to that point. we learned that mib modules for transmission protocols are common, and there is a separate subtree for transmission mib modules. Monitoring the transmission protocols has been important during the growth of SNMP, but it might be less important for netconf. The experimental branch was not very useful because it was too difficult to migrate such a MIB registration afterwards, due to SMI rules that required changing the descriptors, but this might be easier in netconf. If we are going to permit extensibility of capabilities, we might want to be able to use them in an experimental mode first. We do have versioning, so that might make experimental less important, but once published the subtree stays forever. Having some consistency in the top-level organization for MIB modules and YANG modules will probably make it easier to implement applications and instrumentation that use both SNMP and Netconf interfaces. Most operators will want to see some similarity in the data and information models used for configuration and for monitoring. If we design totally different hierarchies, we would likely make it harder and more costly to implement and use, which will not help to encourage adoption of the new standards. So I suggest /ietf /enterprise /iana and maybe /experimental /ietf/transmission /ietf/netconf dbh > -----Original Message----- > From: netconf-bounces@ietf.org > [mailto:netconf-bounces@ietf.org] On Behalf Of Juergen Schoenwaelder > Sent: Tuesday, August 11, 2009 10:25 AM > To: Phil Shafer > Cc: netconf@ietf.org > Subject: Re: [Netconf] Comments on > draft-ietf-netconf-monitoring-06.txt > > On Mon, Aug 10, 2009 at 03:21:59PM +0200, Phil Shafer wrote: > > Andy Bierman writes: > > >but this is protocol name, not WG name. > > > > There should be an organization above the protocol name containing > > the area on which the protocol works. At a minimum, this could be > > the ietf area, but something better (perhaps determined by the > > area directors for that area?) should be easily possible. > > > > A strawman: > > > > /ietf > > + /protocols > > + /management > > + /snmp > > + /netconf > > + /routing > > + /bgp > > + /ospf > > + /layer-2 > > + /spanning-tree > > + /mpls > > + /path-management > > + /rvsp > > + /ldp > > + /security > > + /ipsec > > + /eap > > + /ipr > > + /lawyer-fodder > > > > Or: > > > > /ietf > > + /area > > + /applications > > + /general > > + /internet > > + /oam > > + /netconf > > + /snmp > > + /real-time > > + /routing > > + /mpls > > + /rsvp > > + /ldp > > + /bgp > > + /security > > + /transport > > + /other > > > > Or perhaps put bgp under "egp" and "ospf" and "isis" under "igp". > > Areas come and go, protocols move between areas, everything is > tunneled on top and below everything else (almost). So I believe > the only sensible long lasting structure is > > /ietf/snmp > netconf > bgp > mpls > ... > > and since we use proper namespaces, even the /ietf is not really > adding much in terms of XML processing. > > /js > > -- > 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 mbj@tail-f.com Tue Aug 25 07:18:34 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 9B5693A6F53 for ; Tue, 25 Aug 2009 07:18:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[AWL=0.044, 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 6AXXWXP4O4+X for ; Tue, 25 Aug 2009 07:18:33 -0700 (PDT) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id C5E813A6EDA for ; Tue, 25 Aug 2009 07:18:33 -0700 (PDT) Received: from localhost (c213-100-167-236.swipnet.se [213.100.167.236]) by mail.tail-f.com (Postfix) with ESMTPSA id 0972576C59E; Tue, 25 Aug 2009 16:18:39 +0200 (CEST) Date: Tue, 25 Aug 2009 16:18:38 +0200 (CEST) Message-Id: <20090825.161838.25541126.mbj@tail-f.com> To: ietfdbh@comcast.net From: Martin Bjorklund In-Reply-To: <032d01ca258b$31407470$0600a8c0@china.huawei.com> References: <200908101321.n7ADLxqS058788@idle.juniper.net> <20090811142514.GB1042@elstar.local> <032d01ca258b$31407470$0600a8c0@china.huawei.com> X-Mailer: Mew version 6.0.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] Comments on draft-ietf-netconf-monitoring-06.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: Tue, 25 Aug 2009 14:18:34 -0000 Hi, > So I suggest > /ietf > /enterprise > /iana > and maybe > /experimental > /ietf/transmission > /ietf/netconf One difference if compared to SNMP is that in SNMP there is one single hierarchy, whereas in NETCONF we have a 2-dimensional matrix, or maybe a collection of hierarchies, due to the XML namespace and element names. So in NETCONF, it is perfectly legal to have /ietf in the namespace "urn:ietf:params:xml:ns:ietf" /ietf in the namespace "http://example.com" One consequence of this is that the /experimental subtree is not really needed - one can use the same hierarchy in a different namespace instead (as has been discussed on the NETMOD ML for YANG modules in I-Ds). Another consequence is that the /enterprise subtree is not needed - the enterprise controls its own namespace. If we have an hierarchy starting from /ietf, what will the namespaces be? I would like to avoid extra namespaces as much as possible b/c they get cumbersome to use and get right. /martin From andy@netconfcentral.com Wed Aug 26 09:34: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 C710D3A6CBE for ; Wed, 26 Aug 2009 09:34:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.508 X-Spam-Level: X-Spam-Status: No, score=-2.508 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 EPPX46eIHfdI for ; Wed, 26 Aug 2009 09:34:54 -0700 (PDT) Received: from n13b.bullet.mail.mud.yahoo.com (n13b.bullet.mail.mud.yahoo.com [68.142.207.222]) by core3.amsl.com (Postfix) with SMTP id DD21A3A69F3 for ; Wed, 26 Aug 2009 09:34:53 -0700 (PDT) Received: from [68.142.194.243] by n13.bullet.mail.mud.yahoo.com with NNFMP; 26 Aug 2009 16:34:59 -0000 Received: from [68.142.201.242] by t1.bullet.mud.yahoo.com with NNFMP; 26 Aug 2009 16:34:59 -0000 Received: from [127.0.0.1] by omp403.mail.mud.yahoo.com with NNFMP; 26 Aug 2009 16:34:59 -0000 X-Yahoo-Newman-Id: 17756.52656.bm@omp403.mail.mud.yahoo.com Received: (qmail 12423 invoked from network); 26 Aug 2009 16:34:58 -0000 Received: from unknown (HELO ?192.168.0.10?) (andy@68.120.231.134 with plain) by smtp108.sbc.mail.sp1.yahoo.com with SMTP; 26 Aug 2009 16:34:58 -0000 X-YMail-OSG: hkyDJYgVM1mLG3RoyaDm2ha8vlj_x6FwjOFLNxT.l32qu4UzSKNxjQDWX4q5w80pqLcSMVMhDsuYUHVnfI6eC0Te5aLS_SxhYpe6PXpRPp1RpyCMACEjMa8pgNvlmKjteLx1koO1e6MQ72vB9mRJhtiQ2cMjTimOpm3yIFoJuVq_z6gIA5XwnJDN944zPdTWXf.FUmErb.jPYjE- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4A9563BF.7060908@netconfcentral.com> Date: Wed, 26 Aug 2009 09:33:03 -0700 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] with-defaults terminology conflict 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, 26 Aug 2009 16:34:54 -0000 Hi, This section in with-defaults-03 is a problem: 1.1.2. NETCONF Terms o Default data: Data that is set or used by the NETCONF server whenever the NETCONF client does not provide a specific value for the relevant data item. Default values SHOULD be specified in documents describing the data models supported by the NETCONF server. o Explicitly set default data: Data that is explicitly set by the NETCONF client to its default value. Some servers MAY treat explicitly set default data as simple default data, as they may not be able to differentiate between them. And in 1.2: o trim: Values are not reported if they match the default. ^^^^^^^ IMO, this draft MUST NOT redefine the meaning of a default, as it is specified in YANG. If this draft waits for YANG so it can have a normative YANG module, then the term 'default' must be imported from the YANG RFC. If not, then a consistent definition is needed here. We should have the term 'server-assigned' to mean what the first bullet in 1.1.2 calls 'default data'. o Default data: Data that is set or used by the NETCONF server which contains the schema-specified default value. o Server assigned data: Data that is set or used by the NETCONF server whenever the NETCONF client does not provide a specific value for the relevant data item. These values SHOULD be specified in documents describing the data models supported by the NETCONF server. o Explicitly set default data: Data that is explicitly set by the NETCONF client to its default value. Some servers MAY treat explicitly set default data as simple default data, as they may not be able to differentiate between them. All default data is server-assigned data, but not vice-versa. Andy From Washam.Fan@huaweisymantec.com Sat Aug 29 07:53:34 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 A4E363A6359 for ; Sat, 29 Aug 2009 07:53:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.823 X-Spam-Level: X-Spam-Status: No, score=-0.823 tagged_above=-999 required=5 tests=[AWL=0.287, BAYES_05=-1.11] 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 7iQf72oD92pT for ; Sat, 29 Aug 2009 07:53:34 -0700 (PDT) Received: from mta1.huaweisymantec.com (mta1.huaweisymantec.com [218.17.155.14]) by core3.amsl.com (Postfix) with ESMTP id 76E9D3A6403 for ; Sat, 29 Aug 2009 07:53:13 -0700 (PDT) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-disposition: inline Content-type: text/plain; charset=us-ascii Received: from hstml02-in.huaweisymantec.com ([172.26.3.41]) by hstga01-in.huaweisymantec.com (Sun Java(tm) System Messaging Server 6.3-8.03 (built Apr 24 2009; 32bit)) with ESMTP id <0KP5002KZ8082I00@hstga01-in.huaweisymantec.com> for netconf@ietf.org; Sat, 29 Aug 2009 22:52:57 +0800 (CST) Received: from huaweisymantec.com ([127.0.0.1]) by hstml02-in.huaweisymantec.com (Sun Java(tm) System Messaging Server 6.3-8.03 (built Apr 24 2009; 32bit)) with ESMTP id <0KP500LZA808EF10@hstml02-in.huaweisymantec.com> for netconf@ietf.org; Sat, 29 Aug 2009 22:52:56 +0800 (CST) Received: from [117.79.65.106] by hstml02-in.huaweisymantec.com (mshttpd); Sat, 29 Aug 2009 22:52:56 +0800 From: WashamFan To: Andy Bierman Message-id: Date: Sat, 29 Aug 2009 22:52:56 +0800 X-Mailer: Sun Java(tm) System Messenger Express 6.3-8.03 (built Apr 24 2009; 32bit) Content-language: en X-Accept-Language: en Priority: normal In-reply-to: <4A9563BF.7060908@netconfcentral.com> References: <4A9563BF.7060908@netconfcentral.com> Cc: NETCONF Subject: Re: [Netconf] with-defaults terminology conflict 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, 29 Aug 2009 14:53:34 -0000 Hi, > We should have the term 'server-assigned' to mean what the > first bullet in 1.1.2 calls 'default data'. > > > o Default data: Data that is set or used by the NETCONF server > which contains the schema-specified default value. > > o Server assigned data: Data that is set or used by the NETCONF > server > whenever the NETCONF client does not provide a specific value for > the relevant data item. These values SHOULD be specified in > documents describing the data models supported by the NETCONF > server. I am sorry, that seems not what I infer from discussions in this mailist. server assigned data has no relevant defauts specified in module, it should be set explicitly by server for valid config. washam > o Explicitly set default data: Data that is explicitly set by the > NETCONF client to its default value. Some servers MAY treat > explicitly set default data as simple default data, as they may > not be able to differentiate between them. > > All default data is server-assigned data, but not vice-versa. > > > Andy > > > > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf > From andy@netconfcentral.com Sat Aug 29 08:01:22 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 8538C3A67DA for ; Sat, 29 Aug 2009 08:01:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.498 X-Spam-Level: X-Spam-Status: No, score=-2.498 tagged_above=-999 required=5 tests=[AWL=0.101, 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 5scu-4ljIrOo for ; Sat, 29 Aug 2009 08:01:21 -0700 (PDT) Received: from n67.bullet.mail.sp1.yahoo.com (n67.bullet.mail.sp1.yahoo.com [98.136.44.47]) by core3.amsl.com (Postfix) with SMTP id C6BCA3A68F4 for ; Sat, 29 Aug 2009 08:01:21 -0700 (PDT) Received: from [216.252.122.218] by n67.bullet.mail.sp1.yahoo.com with NNFMP; 29 Aug 2009 15:01:27 -0000 Received: from [68.142.200.227] by t3.bullet.sp1.yahoo.com with NNFMP; 29 Aug 2009 15:01:27 -0000 Received: from [68.142.201.67] by t8.bullet.mud.yahoo.com with NNFMP; 29 Aug 2009 15:01:27 -0000 Received: from [127.0.0.1] by omp419.mail.mud.yahoo.com with NNFMP; 29 Aug 2009 15:01:27 -0000 X-Yahoo-Newman-Id: 419415.61760.bm@omp419.mail.mud.yahoo.com Received: (qmail 46501 invoked from network); 29 Aug 2009 15:01:26 -0000 Received: from unknown (HELO ?192.168.0.10?) (andy@68.120.231.134 with plain) by smtp109.sbc.mail.sp1.yahoo.com with SMTP; 29 Aug 2009 15:01:26 -0000 X-YMail-OSG: 6X59me0VM1kw4cHC_s8X1w.UFNTr3R01bGvFMtDJaS8hpIEjqT8LmfdxvFS.JOAqU.KL2u14gdbRzpEAPvUWKVG9bLYT73FUXv0.xXubHkUTBg6u7vhs.8_7oUWmh3hUujaDD2vxttxiiEL7LKG3QMcSKqkBK30VV7.b4ZsiWMx.AGY3QUU- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4A9942D1.3030003@netconfcentral.com> Date: Sat, 29 Aug 2009 08:01:37 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: WashamFan References: <4A9563BF.7060908@netconfcentral.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: NETCONF Subject: Re: [Netconf] with-defaults terminology conflict 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, 29 Aug 2009 15:01:22 -0000 WashamFan wrote: > Hi, > >> We should have the term 'server-assigned' to mean what the >> first bullet in 1.1.2 calls 'default data'. >> >> >> o Default data: Data that is set or used by the NETCONF server >> which contains the schema-specified default value. >> >> o Server assigned data: Data that is set or used by the NETCONF >> server >> whenever the NETCONF client does not provide a specific value for >> the relevant data item. These values SHOULD be specified in >> documents describing the data models supported by the NETCONF >> server. > > I am sorry, that seems not what I infer from discussions in this mailist. > server assigned data has no relevant defauts specified in module, it > should be set explicitly by server for valid config. > I don't care what the terms are called as long as they align perfectly with the definition of the terms in the YANG draft. Right now "Default data' definition is unacceptable. The with-defaults='trim' behavior MUST be limited to leafs which contain the YANG default-stmt value. > washam Andy From andy@netconfcentral.com Sat Aug 29 08:18:34 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 3778B3A69C1 for ; Sat, 29 Aug 2009 08:18:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.332 X-Spam-Level: X-Spam-Status: No, score=-2.332 tagged_above=-999 required=5 tests=[AWL=-0.067, 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 1NVxo77X9wO7 for ; Sat, 29 Aug 2009 08:18:33 -0700 (PDT) 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 E8B423A6C06 for ; Sat, 29 Aug 2009 08:17:49 -0700 (PDT) Received: (qmail 95962 invoked from network); 29 Aug 2009 15:17:55 -0000 Received: from unknown (HELO ?192.168.0.10?) (andy@68.120.231.134 with plain) by smtp126.sbc.mail.sp1.yahoo.com with SMTP; 29 Aug 2009 15:17:55 -0000 X-YMail-OSG: oWt9_DMVM1mDKlt5QyloF1_Pl693ngmP6zZjiN9Kd6u6xJFAFQsIFcSCBt1xqk.UuKrUER2nkllcrQ.2U5qmGeAmFIq2WHImvuK94MMCwzYXvtDHoZouCkXxJebmNaFmpkupwtCtPimJHb9jr6EaS0D_2fZHH9yfJmpBrbGPijGPBbBJeD4kIEYLSXozRTiJ4v_cWbWwh2PTSqU- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4A9946AE.6070600@netconfcentral.com> Date: Sat, 29 Aug 2009 08:18:06 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: WashamFan References: <4A9563BF.7060908@netconfcentral.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: NETCONF Subject: Re: [Netconf] with-defaults terminology conflict 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, 29 Aug 2009 15:18:34 -0000 WashamFan wrote: > Hi, > >> We should have the term 'server-assigned' to mean what the >> first bullet in 1.1.2 calls 'default data'. >> >> >> o Default data: Data that is set or used by the NETCONF server >> which contains the schema-specified default value. >> >> o Server assigned data: Data that is set or used by the NETCONF >> server >> whenever the NETCONF client does not provide a specific value for >> the relevant data item. These values SHOULD be specified in >> documents describing the data models supported by the NETCONF >> server. > > I am sorry, that seems not what I infer from discussions in this mailist. > server assigned data has no relevant defauts specified in module, it > should be set explicitly by server for valid config. > I'm not sure I really understand your question, but maybe you are pointing out that if the leaf has no default-stmt, then it is never eligible for being trimmed. The NETCONF WG deferred the content layer to the NETMOD WG. The NETMOD WG is now defining the content layer for ALL OF NETCONF. After YANG is published, there will be non-standard NETCONF data and YANG NETCONF data, and nothing in between. The mechanisms defined in NETCONF MUST align perfectly with the definitions of the content model defined by YANG. It is absolutely unacceptable for a NETCONF server vendor to be able to say "oh, those rules don't apply to my YANG modules, because I follow my own 'FUBAR' capability, and I have my own definition of a 'default' (or 'mandatory', or whatever). It's OK because the :with-defaults standard does it too." o Default data: Data that is set or used by the NETCONF server whenever the NETCONF client does not provide a specific value for the relevant data item. Default values SHOULD be specified in documents describing the data models supported by the NETCONF server. This is NOT what a default is in YANG, so therefore this definition is incorrect for all YANG content. > washam Andy From Washam.Fan@huaweisymantec.com Sat Aug 29 08:23: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 8C80D3A6C06 for ; Sat, 29 Aug 2009 08:23:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.544 X-Spam-Level: X-Spam-Status: No, score=-0.544 tagged_above=-999 required=5 tests=[AWL=-0.049, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HrJiH3GSBFfu for ; Sat, 29 Aug 2009 08:23:53 -0700 (PDT) Received: from mta2.huaweisymantec.com (unknown [218.17.155.15]) by core3.amsl.com (Postfix) with ESMTP id 9E7853A6AD1 for ; Sat, 29 Aug 2009 08:23:53 -0700 (PDT) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-disposition: inline Content-type: text/plain; charset=us-ascii Received: from hstml02-in.huaweisymantec.com ([172.26.3.42]) by hstga02-in.huaweisymantec.com (Sun Java(tm) System Messaging Server 6.3-8.03 (built Apr 24 2009; 32bit)) with ESMTP id <0KP50034K9EVNV60@hstga02-in.huaweisymantec.com> for netconf@ietf.org; Sat, 29 Aug 2009 23:23:20 +0800 (CST) Received: from huaweisymantec.com ([127.0.0.1]) by hstml02-in.huaweisymantec.com (Sun Java(tm) System Messaging Server 6.3-8.03 (built Apr 24 2009; 32bit)) with ESMTP id <0KP500MZN9EVMZ10@hstml02-in.huaweisymantec.com> for netconf@ietf.org; Sat, 29 Aug 2009 23:23:19 +0800 (CST) Received: from [117.79.65.106] by hstml02-in.huaweisymantec.com (mshttpd); Sat, 29 Aug 2009 23:23:19 +0800 From: WashamFan To: Andy Bierman Message-id: Date: Sat, 29 Aug 2009 23:23:19 +0800 X-Mailer: Sun Java(tm) System Messenger Express 6.3-8.03 (built Apr 24 2009; 32bit) Content-language: en X-Accept-Language: en Priority: normal In-reply-to: <4A9942D1.3030003@netconfcentral.com> References: <4A9563BF.7060908@netconfcentral.com> <4A9942D1.3030003@netconfcentral.com> Cc: NETCONF Subject: Re: [Netconf] with-defaults terminology conflict 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, 29 Aug 2009 15:23:54 -0000 > WashamFan wrote: > > Hi, > > > >> We should have the term 'server-assigned' to mean what the > >> first bullet in 1.1.2 calls 'default data'. > >> > >> > >> o Default data: Data that is set or used by the NETCONF server > >> which contains the schema-specified default value. > >> > >> o Server assigned data: Data that is set or used by the > NETCONF > >> server > >> whenever the NETCONF client does not provide a specific > value for > >> the relevant data item. These values SHOULD be specified in > >> documents describing the data models supported by the NETCONF > >> server. > > > > I am sorry, that seems not what I infer from discussions in this mailist. > > server assigned data has no relevant defauts specified in module, it > > should be set explicitly by server for valid config. > > > > I don't care what the terms are called > as long as they align perfectly with > the definition of the terms in the YANG draft. > > Right now "Default data' definition is unacceptable. > > The with-defaults='trim' behavior MUST be limited to > leafs which contain the YANG default-stmt value. Is server assigned data (bullet 2) with or without default-stmt? And how should server return data in when with-defaults is set to 'trim' 'explicit' 'report-all' respectively? washam From andy@netconfcentral.com Sat Aug 29 08:43: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 74F1E3A684E for ; Sat, 29 Aug 2009 08:43:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.331 X-Spam-Level: X-Spam-Status: No, score=-2.331 tagged_above=-999 required=5 tests=[AWL=-0.066, 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 r0Q3kz3p7F+M for ; Sat, 29 Aug 2009 08:43:19 -0700 (PDT) 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 E33BD3A6C67 for ; Sat, 29 Aug 2009 08:43:00 -0700 (PDT) Received: (qmail 37624 invoked from network); 29 Aug 2009 15:43:05 -0000 Received: from unknown (HELO ?192.168.0.10?) (andy@68.120.231.134 with plain) by smtp125.sbc.mail.sp1.yahoo.com with SMTP; 29 Aug 2009 15:43:05 -0000 X-YMail-OSG: rNe80_4VM1nFI39PDWme.Gf.mHCpvwYRlDYuOABGNLgCwHs85Nim.X8ngPjv2udtM9M5oZxcRe7S6zLBskaZHeS8i1c3gcYSt6QVCSHE_Mr3CFFREveAOuA5EE0xM2qHYGyh_FOZ.0GipBQW0kVcm9cR8yFlyMKQ0P_1fuNvKXVFTCtZP7Gqglh7CAFodhg..JSP0GahgUGs_6Y- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4A994C94.7020600@netconfcentral.com> Date: Sat, 29 Aug 2009 08:43:16 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: WashamFan References: <4A9563BF.7060908@netconfcentral.com> <4A9942D1.3030003@netconfcentral.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: NETCONF Subject: Re: [Netconf] with-defaults terminology conflict 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, 29 Aug 2009 15:43:20 -0000 WashamFan wrote: >> WashamFan wrote: >> > Hi, >> > >> >> We should have the term 'server-assigned' to mean what the >> >> first bullet in 1.1.2 calls 'default data'. >> >> >> >> >> >> o Default data: Data that is set or used by the NETCONF server >> >> which contains the schema-specified default value. >> >> >> >> o Server assigned data: Data that is set or used by the >> NETCONF >> >> server >> >> whenever the NETCONF client does not provide a specific >> value for >> >> the relevant data item. These values SHOULD be specified in >> >> documents describing the data models supported by the NETCONF >> >> server. >> > >> > I am sorry, that seems not what I infer from discussions in this mailist. >> > server assigned data has no relevant defauts specified in module, it >> > should be set explicitly by server for valid config. >> > >> >> I don't care what the terms are called >> as long as they align perfectly with >> the definition of the terms in the YANG draft. >> >> Right now "Default data' definition is unacceptable. >> >> The with-defaults='trim' behavior MUST be limited to >> leafs which contain the YANG default-stmt value. > > Is server assigned data (bullet 2) with or without default-stmt? with -- it is intended to be everything filtered out for 'explicit'. So, here is the simplified version of what if filtered out (not returned): trim == leafs set to their YANG default-stmt value explicit == leafs that match the 'server-assigned data' definition report-all == nothing. nada. zip. every leaf is returned. nothing is filtered out. > And how should server return data in when with-defaults > is set to 'trim' 'explicit' 'report-all' respectively? > > washam > > Andy From j.schoenwaelder@jacobs-university.de Sat Aug 29 08:58:34 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 728DB3A6B9C for ; Sat, 29 Aug 2009 08:58:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.15 X-Spam-Level: X-Spam-Status: No, score=-2.15 tagged_above=-999 required=5 tests=[AWL=0.099, 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 BYaND4B1lC5c for ; Sat, 29 Aug 2009 08:58:33 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id DAE6F3A6ABC for ; Sat, 29 Aug 2009 08:58:29 -0700 (PDT) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id E507EC001E; Sat, 29 Aug 2009 17:58:35 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius4.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id FyXeqJvU6AtJ; Sat, 29 Aug 2009 17:58:34 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 7F95FC001F; Sat, 29 Aug 2009 17:58:34 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 9E020C82A04; Sat, 29 Aug 2009 17:58:32 +0200 (CEST) Date: Sat, 29 Aug 2009 17:58:32 +0200 From: Juergen Schoenwaelder To: Andy Bierman Message-ID: <20090829155832.GA24264@elstar.local> Mail-Followup-To: Andy Bierman , WashamFan , NETCONF References: <4A9563BF.7060908@netconfcentral.com> <4A9942D1.3030003@netconfcentral.com> <4A994C94.7020600@netconfcentral.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4A994C94.7020600@netconfcentral.com> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: NETCONF Subject: Re: [Netconf] with-defaults terminology conflict 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: Sat, 29 Aug 2009 15:58:34 -0000 On Sat, Aug 29, 2009 at 05:43:16PM +0200, Andy Bierman wrote: > So, here is the simplified version of what if filtered out (not returned): > > trim == leafs set to their YANG default-stmt value > explicit == leafs that match the 'server-assigned data' definition > report-all == nothing. nada. zip. every leaf is returned. nothing > is filtered out. Still wrong. Explicit does simply not have config leafes where there is no config. There is no filtering with explicit. See also Phil's email. We are going in circles. I guess we need help from the chairs to move forward. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From jmh@joelhalpern.com Sat Aug 29 09:18: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 E362C3A6C07 for ; Sat, 29 Aug 2009 09:18:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.443 X-Spam-Level: X-Spam-Status: No, score=-3.443 tagged_above=-999 required=5 tests=[AWL=0.156, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J-nK3MhjE3My for ; Sat, 29 Aug 2009 09:18:56 -0700 (PDT) Received: from hermes.mail.tigertech.net (hermes.mail.tigertech.net [64.62.209.72]) by core3.amsl.com (Postfix) with ESMTP id 27CFA3A6BFD for ; Sat, 29 Aug 2009 09:18:56 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 701D9430584 for ; Sat, 29 Aug 2009 09:19:03 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hermes.tigertech.net Received: from [10.10.10.101] (pool-71-161-51-226.clppva.btas.verizon.net [71.161.51.226]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by hermes.tigertech.net (Postfix) with ESMTP id DC68F43057E for ; Sat, 29 Aug 2009 09:19:02 -0700 (PDT) Message-ID: <4A9954F1.3040204@joelhalpern.com> Date: Sat, 29 Aug 2009 12:18:57 -0400 From: "Joel M. Halpern" User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: NETCONF References: <4A9563BF.7060908@netconfcentral.com> <4A9942D1.3030003@netconfcentral.com> <4A994C94.7020600@netconfcentral.com> <20090829155832.GA24264@elstar.local> In-Reply-To: <20090829155832.GA24264@elstar.local> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Netconf] with-defaults terminology conflict 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, 29 Aug 2009 16:18:57 -0000 From reading the model, how am I supposed to tell which of the nodes that do not have config leaves, but for which the server is using values, will be filtered? And why are those values not being set in the config structure. For values which have no meaning past when they are used, I can understand wanting to filter them. For values which are a simple reference to some other variable, and which change with that variable, I can understand not representing the value, although I am not sure whether that is right. For other values, I can not see any justification for not representing them. They need to be accessible to the management system. Otherwise, the system is liable to set them, in order to avoid pathologies. And the odds are those values will be worse than the ones the system would choose. The length issue seems to turn on who is processing this information. Machinery can deal with the length we are discussing. Yours, Joel Juergen Schoenwaelder wrote: > On Sat, Aug 29, 2009 at 05:43:16PM +0200, Andy Bierman wrote: > >> So, here is the simplified version of what if filtered out (not returned): >> >> trim == leafs set to their YANG default-stmt value >> explicit == leafs that match the 'server-assigned data' definition >> report-all == nothing. nada. zip. every leaf is returned. nothing >> is filtered out. > > Still wrong. Explicit does simply not have config leafes where there > is no config. There is no filtering with explicit. See also Phil's > email. We are going in circles. I guess we need help from the chairs > to move forward. > > /js > From Washam.Fan@huaweisymantec.com Sat Aug 29 09:21:04 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 45C363A6D17 for ; Sat, 29 Aug 2009 09:21:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.592 X-Spam-Level: X-Spam-Status: No, score=-1.592 tagged_above=-999 required=5 tests=[AWL=1.008, 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 pueaIO4Z6EKe for ; Sat, 29 Aug 2009 09:21:03 -0700 (PDT) Received: from mta1.huaweisymantec.com (mta1.huaweisymantec.com [218.17.155.14]) by core3.amsl.com (Postfix) with ESMTP id 5C2693A6BFD for ; Sat, 29 Aug 2009 09:21:03 -0700 (PDT) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-disposition: inline Content-type: text/plain; charset=us-ascii Received: from hstml02-in.huaweisymantec.com ([172.26.3.41]) by hstga01-in.huaweisymantec.com (Sun Java(tm) System Messaging Server 6.3-8.03 (built Apr 24 2009; 32bit)) with ESMTP id <0KP5002H1C2O2I10@hstga01-in.huaweisymantec.com> for netconf@ietf.org; Sun, 30 Aug 2009 00:20:49 +0800 (CST) Received: from huaweisymantec.com ([127.0.0.1]) by hstml02-in.huaweisymantec.com (Sun Java(tm) System Messaging Server 6.3-8.03 (built Apr 24 2009; 32bit)) with ESMTP id <0KP500M4JC2O7Y20@hstml02-in.huaweisymantec.com> for netconf@ietf.org; Sun, 30 Aug 2009 00:20:48 +0800 (CST) Received: from [117.79.65.106] by hstml02-in.huaweisymantec.com (mshttpd); Sun, 30 Aug 2009 00:20:48 +0800 From: WashamFan To: Andy Bierman Message-id: Date: Sun, 30 Aug 2009 00:20:48 +0800 X-Mailer: Sun Java(tm) System Messenger Express 6.3-8.03 (built Apr 24 2009; 32bit) Content-language: en X-Accept-Language: en Priority: normal In-reply-to: <4A994C94.7020600@netconfcentral.com> References: <4A9563BF.7060908@netconfcentral.com> <4A9942D1.3030003@netconfcentral.com> <4A994C94.7020600@netconfcentral.com> Cc: NETCONF Subject: Re: [Netconf] with-defaults terminology conflict 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, 29 Aug 2009 16:21:04 -0000 > >> WashamFan wrote: > >> > Hi, > >> > > >> >> We should have the term 'server-assigned' to mean what the > >> >> first bullet in 1.1.2 calls 'default data'. > >> >> > >> >> > >> >> o Default data: Data that is set or used by the NETCONF server > >> >> which contains the schema-specified default value. > >> >> > >> >> o Server assigned data: Data that is set or used by the > > >> NETCONF > >> >> server > >> >> whenever the NETCONF client does not provide a specific > > >> value for > >> >> the relevant data item. These values SHOULD be > specified in > >> >> documents describing the data models supported by the NETCONF > >> >> server. > >> > > >> > I am sorry, that seems not what I infer from discussions in > this mailist. > >> > server assigned data has no relevant defauts specified in > module, it > >> > should be set explicitly by server for valid config. > >> > > >> > >> I don't care what the terms are called > >> as long as they align perfectly with > >> the definition of the terms in the YANG draft. > >> > >> Right now "Default data' definition is unacceptable. > >> > >> The with-defaults='trim' behavior MUST be limited to > >> leafs which contain the YANG default-stmt value. > > > > Is server assigned data (bullet 2) with or without default-stmt? > > with -- it is intended to be everything filtered out for 'explicit'. I think this is where we disagree. If a leaf with a default-stmt, it is either set explicitly by the client or set to the value specified in default-stmt when it is "used internally by the server". In the latter case, it is the data that would be filtered out by trim. In the former case, if the value is set to the value defined in default-stmt, then it is the data that would be filtered by explicit, otherwise, it should not be filtered out in any cases and would be reported always. Any leaf without a default-stmt should be reported always if it exists in data tree. washam > So, here is the simplified version of what if filtered out (not returned): > > trim == leafs set to their YANG default-stmt value > explicit == leafs that match the 'server-assigned data' definition > report-all == nothing. nada. zip. every leaf is returned. nothing > is filtered out. > > > > And how should server return data in when with-defaults > > is set to 'trim' 'explicit' 'report-all' respectively? > > > > washam > > > > > > > Andy > > From andy@netconfcentral.com Sat Aug 29 09:29:28 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 2B8A83A6948 for ; Sat, 29 Aug 2009 09:29:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.498 X-Spam-Level: X-Spam-Status: No, score=-2.498 tagged_above=-999 required=5 tests=[AWL=0.101, 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 ea+FduokSyKG for ; Sat, 29 Aug 2009 09:29:27 -0700 (PDT) Received: from n18.bullet.mail.mud.yahoo.com (n18.bullet.mail.mud.yahoo.com [68.142.206.145]) by core3.amsl.com (Postfix) with SMTP id 4D7543A68AB for ; Sat, 29 Aug 2009 09:29:27 -0700 (PDT) Received: from [68.142.200.221] by n18.bullet.mail.mud.yahoo.com with NNFMP; 29 Aug 2009 16:29:32 -0000 Received: from [68.142.201.250] by t9.bullet.mud.yahoo.com with NNFMP; 29 Aug 2009 16:29:32 -0000 Received: from [127.0.0.1] by omp411.mail.mud.yahoo.com with NNFMP; 29 Aug 2009 16:29:32 -0000 X-Yahoo-Newman-Id: 931027.35273.bm@omp411.mail.mud.yahoo.com Received: (qmail 62568 invoked from network); 29 Aug 2009 16:29:32 -0000 Received: from unknown (HELO ?192.168.0.10?) (andy@68.120.231.134 with plain) by smtp106.sbc.mail.sp1.yahoo.com with SMTP; 29 Aug 2009 16:29:32 -0000 X-YMail-OSG: hHW9ExgVM1k6OI.6qzQyrn9NWDFsaFbSsTJf.HWe6c.98fMuvMRdZUL.ikEl5OVEbfUfCZBxfurqftQShoP.WjvfGKs_FHzMQ1R6KfMde7ILMQOEEazEx1xDb5EtvCa6LQmV3PXnHW7_vctJN2T9aBz3GXhm15ksp8EgOCh8aDrIRLy77G4GhXw95SoxdroF3o1ooCF2xfuOM6E- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4A9956FF.50409@netconfcentral.com> Date: Sat, 29 Aug 2009 09:27:43 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: Andy Bierman , WashamFan , NETCONF References: <4A9563BF.7060908@netconfcentral.com> <4A9942D1.3030003@netconfcentral.com> <4A994C94.7020600@netconfcentral.com> <20090829155832.GA24264@elstar.local> In-Reply-To: <20090829155832.GA24264@elstar.local> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [Netconf] with-defaults terminology conflict 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, 29 Aug 2009 16:29:28 -0000 Juergen Schoenwaelder wrote: > On Sat, Aug 29, 2009 at 05:43:16PM +0200, Andy Bierman wrote: > >> So, here is the simplified version of what if filtered out (not returned): >> >> trim == leafs set to their YANG default-stmt value >> explicit == leafs that match the 'server-assigned data' definition >> report-all == nothing. nada. zip. every leaf is returned. nothing >> is filtered out. > > Still wrong. Explicit does simply not have config leafes where there > is no config. There is no filtering with explicit. See also Phil's > email. We are going in circles. I guess we need help from the chairs > to move forward. I never said that, but I should have put 'instance of a leaf' everywhere. A 'leaf' is an object when referring to the schema tree. Since only instances of a leaf can possibly be retrieved with , , and , I thought it was obvious I was referring to instances of a leaf. Obviously not. > > /js > Andy From Washam.Fan@huaweisymantec.com Sat Aug 29 09:30: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 9A4F93A6B9B for ; Sat, 29 Aug 2009 09:30:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.623 X-Spam-Level: X-Spam-Status: No, score=-0.623 tagged_above=-999 required=5 tests=[AWL=-0.128, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DdwZwhjHx3dn for ; Sat, 29 Aug 2009 09:30:46 -0700 (PDT) Received: from mta2.huaweisymantec.com (unknown [218.17.155.15]) by core3.amsl.com (Postfix) with ESMTP id CB25E3A6948 for ; Sat, 29 Aug 2009 09:30:45 -0700 (PDT) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-disposition: inline Content-type: text/plain; charset=us-ascii Received: from hstml02-in.huaweisymantec.com ([172.26.3.42]) by hstga02-in.huaweisymantec.com (Sun Java(tm) System Messaging Server 6.3-8.03 (built Apr 24 2009; 32bit)) with ESMTP id <0KP5003STCJ6NV60@hstga02-in.huaweisymantec.com> for netconf@ietf.org; Sun, 30 Aug 2009 00:30:42 +0800 (CST) Received: from huaweisymantec.com ([127.0.0.1]) by hstml02-in.huaweisymantec.com (Sun Java(tm) System Messaging Server 6.3-8.03 (built Apr 24 2009; 32bit)) with ESMTP id <0KP500L3NCJ6M920@hstml02-in.huaweisymantec.com> for netconf@ietf.org; Sun, 30 Aug 2009 00:30:42 +0800 (CST) Received: from [117.79.65.106] by hstml02-in.huaweisymantec.com (mshttpd); Sun, 30 Aug 2009 00:30:42 +0800 From: WashamFan To: WashamFan Message-id: Date: Sun, 30 Aug 2009 00:30:42 +0800 X-Mailer: Sun Java(tm) System Messenger Express 6.3-8.03 (built Apr 24 2009; 32bit) Content-language: en X-Accept-Language: en Priority: normal In-reply-to: References: <4A9563BF.7060908@netconfcentral.com> <4A9942D1.3030003@netconfcentral.com> <4A994C94.7020600@netconfcentral.com> Cc: NETCONF Subject: Re: [Netconf] with-defaults terminology conflict 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, 29 Aug 2009 16:30:46 -0000 Hi, Do correction. See inline. washam > I think this is where we disagree. If a leaf with a default-stmt, it > is either > set explicitly by the client or set to the value > specified in default-stmt when it is "used internally by the server". > > In the latter case, it is the data > that would be filtered out by trim. s/trim/trim and explicit/ > In the former case, if the value > is set > to the value defined in default-stmt, then it is the data that would > be filtered by explicit, s/explicit/trim/ > otherwise, it should not be filtered out in > any cases > and would be reported always. > > Any leaf without a default-stmt should be reported always if it > exists in > data tree. > > washam From andy@netconfcentral.com Sat Aug 29 09:42: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 2F93C28C107 for ; Sat, 29 Aug 2009 09:42:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.498 X-Spam-Level: X-Spam-Status: No, score=-2.498 tagged_above=-999 required=5 tests=[AWL=0.101, 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 KCZ0+BF8triq for ; Sat, 29 Aug 2009 09:42:08 -0700 (PDT) Received: from n10.bullet.mail.mud.yahoo.com (n10.bullet.mail.mud.yahoo.com [209.191.125.208]) by core3.amsl.com (Postfix) with SMTP id 3C14528C0F4 for ; Sat, 29 Aug 2009 09:42:08 -0700 (PDT) Received: from [68.142.194.243] by n10.bullet.mail.mud.yahoo.com with NNFMP; 29 Aug 2009 16:42:13 -0000 Received: from [68.142.201.248] by t1.bullet.mud.yahoo.com with NNFMP; 29 Aug 2009 16:42:13 -0000 Received: from [127.0.0.1] by omp409.mail.mud.yahoo.com with NNFMP; 29 Aug 2009 16:42:13 -0000 X-Yahoo-Newman-Id: 830328.41929.bm@omp409.mail.mud.yahoo.com Received: (qmail 38815 invoked from network); 29 Aug 2009 16:42:13 -0000 Received: from unknown (HELO ?192.168.0.10?) (andy@68.120.231.134 with plain) by smtp105.sbc.mail.sp1.yahoo.com with SMTP; 29 Aug 2009 16:42:13 -0000 X-YMail-OSG: SbKNlpkVM1nKjkxDW_eAgMq5xENe9NcRoyDXXrhwF.WF8SNDSbMEilWRoaCjoASfVbA0DqvMlwqF4MqFUtU.mv.fZDNzuryoxTgwGA0A5Ynkubf86zv23i1eDEfO4klMGwfiBmQSbomCTbYh3hXAy6cye0jPaengqoEo5SZVXBHgMAD9ohGZifQQo_h5OzhqoWDc2kIAvLszUcE- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4A9959F4.20705@netconfcentral.com> Date: Sat, 29 Aug 2009 09:40:20 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: "Joel M. Halpern" References: <4A9563BF.7060908@netconfcentral.com> <4A9942D1.3030003@netconfcentral.com> <4A994C94.7020600@netconfcentral.com> <20090829155832.GA24264@elstar.local> <4A9954F1.3040204@joelhalpern.com> In-Reply-To: <4A9954F1.3040204@joelhalpern.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: NETCONF Subject: Re: [Netconf] with-defaults terminology conflict 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, 29 Aug 2009 16:42:09 -0000 Joel M. Halpern wrote: > From reading the model, how am I supposed to tell which of the nodes > that do not have config leaves, but for which the server is using > values, will be filtered? The official answer is that the appropriate documentation will contain this information. The unofficial answer: you do what application developers have always done trying to manage networking devices. You hire lots of engineers to do trial-and-error data-silo construction. > > And why are those values not being set in the config structure. > For values which have no meaning past when they are used, I can > understand wanting to filter them. They are in the configuration, otherwise they could not possibly cause an error during database validation. There is nothing whatsoever in YANG (except the YANG default-stmt) that would give you any definitive value as a substitute for a leaf instance the server is using, which is not available for retrieval. > For values which are a simple reference to some other variable, and > which change with that variable, I can understand not representing the > value, although I am not sure whether that is right. > For other values, I can not see any justification for not representing > them. They need to be accessible to the management system. Otherwise, > the system is liable to set them, in order to avoid pathologies. And > the odds are those values will be worse than the ones the system would > choose. > > The length issue seems to turn on who is processing this information. > Machinery can deal with the length we are discussing. > Back in SNMP days, we thought it was a good idea that a dumb MIB walker could show you the data from any SNMP agent in the world, without knowing about even 1 MIB object definition on that agent. That's what we thought true decoupling of the protocol and the data definition language meant. > Yours, > Joel > Andy From j.schoenwaelder@jacobs-university.de Sat Aug 29 11:20: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 6C7C73A6A24 for ; Sat, 29 Aug 2009 11:20:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.15 X-Spam-Level: X-Spam-Status: No, score=-2.15 tagged_above=-999 required=5 tests=[AWL=0.099, 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 ZOpKf0bcx+nw for ; Sat, 29 Aug 2009 11:20:15 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 938C33A68E9 for ; Sat, 29 Aug 2009 11:20:14 -0700 (PDT) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 1E95DC001F; Sat, 29 Aug 2009 20:20:21 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius4.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id Ms36AqvLaShW; Sat, 29 Aug 2009 20:20:20 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 78589C000D; Sat, 29 Aug 2009 20:20:19 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id F15FFC82B28; Sat, 29 Aug 2009 20:20:17 +0200 (CEST) Date: Sat, 29 Aug 2009 20:20:17 +0200 From: Juergen Schoenwaelder To: "Joel M. Halpern" Message-ID: <20090829182017.GA24348@elstar.local> Mail-Followup-To: "Joel M. Halpern" , NETCONF References: <4A9563BF.7060908@netconfcentral.com> <4A9942D1.3030003@netconfcentral.com> <4A994C94.7020600@netconfcentral.com> <20090829155832.GA24264@elstar.local> <4A9954F1.3040204@joelhalpern.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4A9954F1.3040204@joelhalpern.com> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: NETCONF Subject: Re: [Netconf] with-defaults terminology conflict 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: Sat, 29 Aug 2009 18:20:16 -0000 On Sat, Aug 29, 2009 at 06:18:57PM +0200, Joel M. Halpern wrote: > For other values, I can not see any justification for not representing > them. They need to be accessible to the management system. Accessible yes, but they are not part of the configuration. > The length issue seems to turn on who is processing this > information. Machinery can deal with the length we are discussing. Making operational state by default is broken. It is wrong in most cases to treat the MTU as config since what you want is likely the value the kernel figured out for the piece of hardware you are currently using. We are caught in circles. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From j.schoenwaelder@jacobs-university.de Sat Aug 29 11:23: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 9345F3A6ABD for ; Sat, 29 Aug 2009 11:23:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.151 X-Spam-Level: X-Spam-Status: No, score=-2.151 tagged_above=-999 required=5 tests=[AWL=0.098, 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 lzi8hTIsZdcD for ; Sat, 29 Aug 2009 11:23:32 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 6839D3A6AA4 for ; Sat, 29 Aug 2009 11:23:03 -0700 (PDT) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 4F5B2C001E; Sat, 29 Aug 2009 20:23:10 +0200 (CEST) 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 SUhf5AvEtZz7; Sat, 29 Aug 2009 20:23:09 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id D403FC000D; Sat, 29 Aug 2009 20:23:08 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 6E683C82B6D; Sat, 29 Aug 2009 20:23:07 +0200 (CEST) Date: Sat, 29 Aug 2009 20:23:07 +0200 From: Juergen Schoenwaelder To: Andy Bierman Message-ID: <20090829182307.GB24348@elstar.local> Mail-Followup-To: Andy Bierman , "Joel M. Halpern" , NETCONF References: <4A9563BF.7060908@netconfcentral.com> <4A9942D1.3030003@netconfcentral.com> <4A994C94.7020600@netconfcentral.com> <20090829155832.GA24264@elstar.local> <4A9954F1.3040204@joelhalpern.com> <4A9959F4.20705@netconfcentral.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4A9959F4.20705@netconfcentral.com> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: NETCONF Subject: Re: [Netconf] with-defaults terminology conflict 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: Sat, 29 Aug 2009 18:23:33 -0000 On Sat, Aug 29, 2009 at 06:40:20PM +0200, Andy Bierman wrote: > Joel M. Halpern wrote: > > From reading the model, how am I supposed to tell which of the nodes > > that do not have config leaves, but for which the server is using > > values, will be filtered? > > The official answer is that the appropriate documentation will > contain this information. > > The unofficial answer: you do what application developers have > always done trying to manage networking devices. You hire > lots of engineers to do trial-and-error data-silo construction. Both your answers. Both wrong. Explicit means no filtering. Explicit means config is config and operational state is operational state. If you want config, you do a get-config. If you want operational state, you do get or something specific for retrieving operational state. > Back in SNMP days, we thought it was a good idea that a dumb > MIB walker could show you the data from any SNMP agent in the world, > without knowing about even 1 MIB object definition on that agent. > > That's what we thought true decoupling of the > protocol and the data definition language meant. Read RFC 3535 to find out why the lack of separation of config data from state and statistics was a mistake. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From j.schoenwaelder@jacobs-university.de Sat Aug 29 11:28: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 499F03A69D9 for ; Sat, 29 Aug 2009 11:28:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.152 X-Spam-Level: X-Spam-Status: No, score=-2.152 tagged_above=-999 required=5 tests=[AWL=0.097, 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 ZQVlbkMXReva for ; Sat, 29 Aug 2009 11:28:56 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 1D1DD3A6901 for ; Sat, 29 Aug 2009 11:28:56 -0700 (PDT) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id 05513C000D; Sat, 29 Aug 2009 20:29:03 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius1.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id iXaGgr0USjs7; Sat, 29 Aug 2009 20:29:02 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 1DCBEC0026; Sat, 29 Aug 2009 20:29:01 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 3BDB1C82BDB; Sat, 29 Aug 2009 20:29:00 +0200 (CEST) Date: Sat, 29 Aug 2009 20:29:00 +0200 From: Juergen Schoenwaelder To: Andy Bierman Message-ID: <20090829182900.GC24348@elstar.local> Mail-Followup-To: Andy Bierman , WashamFan , NETCONF References: <4A9563BF.7060908@netconfcentral.com> <4A9942D1.3030003@netconfcentral.com> <4A994C94.7020600@netconfcentral.com> <20090829155832.GA24264@elstar.local> <4A9956FF.50409@netconfcentral.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4A9956FF.50409@netconfcentral.com> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: NETCONF Subject: Re: [Netconf] with-defaults terminology conflict 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: Sat, 29 Aug 2009 18:28:57 -0000 On Sat, Aug 29, 2009 at 06:27:43PM +0200, Andy Bierman wrote: > Juergen Schoenwaelder wrote: > > On Sat, Aug 29, 2009 at 05:43:16PM +0200, Andy Bierman wrote: > > > >> So, here is the simplified version of what if filtered out (not returned): > >> > >> trim == leafs set to their YANG default-stmt value > >> explicit == leafs that match the 'server-assigned data' definition > >> report-all == nothing. nada. zip. every leaf is returned. nothing > >> is filtered out. > > > > Still wrong. Explicit does simply not have config leafes where there > > is no config. There is no filtering with explicit. See also Phil's > > email. We are going in circles. I guess we need help from the chairs > > to move forward. > > I never said that, but I should have put 'instance of a leaf' everywhere. > > A 'leaf' is an object when referring to the schema tree. > > Since only instances of a leaf can possibly be retrieved > with , , and , I thought it was > obvious I was referring to instances of a leaf. Obviously not. As I said, we obviously need help from the chairs - we seem to talk past each other for a while now and this is not effective. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From jmh@joelhalpern.com Sat Aug 29 11:32: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 14CA83A6B35; Sat, 29 Aug 2009 11:32:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.444 X-Spam-Level: X-Spam-Status: No, score=-3.444 tagged_above=-999 required=5 tests=[AWL=0.155, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DYUFeB6ev8WZ; Sat, 29 Aug 2009 11:32:30 -0700 (PDT) Received: from hermes.mail.tigertech.net (hermes.mail.tigertech.net [64.62.209.72]) by core3.amsl.com (Postfix) with ESMTP id 5B2EB3A69D9; Sat, 29 Aug 2009 11:32:30 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id C9073430593; Sat, 29 Aug 2009 11:32:37 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hermes.tigertech.net Received: from [10.10.10.101] (pool-71-161-51-226.clppva.btas.verizon.net [71.161.51.226]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by hermes.tigertech.net (Postfix) with ESMTP id 359CB430590; Sat, 29 Aug 2009 11:32:37 -0700 (PDT) Message-ID: <4A99743F.8040902@joelhalpern.com> Date: Sat, 29 Aug 2009 14:32:31 -0400 From: "Joel M. Halpern" User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: NETCONF , NETMOD Working Group References: <4A9563BF.7060908@netconfcentral.com> <4A9942D1.3030003@netconfcentral.com> <4A994C94.7020600@netconfcentral.com> <20090829155832.GA24264@elstar.local> <4A9954F1.3040204@joelhalpern.com> <20090829182017.GA24348@elstar.local> In-Reply-To: <20090829182017.GA24348@elstar.local> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Netconf] with-defaults terminology conflict 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, 29 Aug 2009 18:32:31 -0000 I have, in previous notes, said that representing the "currently used mtu" as operational data would be a reasonable approach. I can even live with the fact that the coupling between the configured value and the operational value is weak / description based. But, every time I have suggested that, Phil (who is the most vocal proponent of the view that such information should not appear in the config), has vehemently asserted that he does not want to represent it as operational data. I readily admit that there are multiple ways to solve the problem. What I am not prepared to admit is that "read the documentation and attempt to recreate the document device calculation in the manager" is even vaguely appropriate as a solution. Nor am I prepared to agree that there is not a problem. Yours, Joel PS: I copied netmod, because I thought that was where this was being discussed for the most part. It clearly crosses the boundaries between the two. Juergen Schoenwaelder wrote: > On Sat, Aug 29, 2009 at 06:18:57PM +0200, Joel M. Halpern wrote: > >> For other values, I can not see any justification for not representing >> them. They need to be accessible to the management system. > > Accessible yes, but they are not part of the configuration. > >> The length issue seems to turn on who is processing this >> information. Machinery can deal with the length we are discussing. > > Making operational state by default is broken. It is wrong in most > cases to treat the MTU as config since what you want is likely the > value the kernel figured out for the piece of hardware you are > currently using. We are caught in circles. > > /js > From andy@netconfcentral.com Sat Aug 29 11:53:04 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 6D5013A6A72 for ; Sat, 29 Aug 2009 11:53:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.499 X-Spam-Level: X-Spam-Status: No, score=-2.499 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 5YHx3qgtlgZz for ; Sat, 29 Aug 2009 11:53:03 -0700 (PDT) Received: from n18.bullet.mail.mud.yahoo.com (n18.bullet.mail.mud.yahoo.com [68.142.206.145]) by core3.amsl.com (Postfix) with SMTP id 336AA3A6979 for ; Sat, 29 Aug 2009 11:52:34 -0700 (PDT) Received: from [68.142.200.227] by n18.bullet.mail.mud.yahoo.com with NNFMP; 29 Aug 2009 18:52:39 -0000 Received: from [68.142.201.249] by t8.bullet.mud.yahoo.com with NNFMP; 29 Aug 2009 18:52:39 -0000 Received: from [127.0.0.1] by omp410.mail.mud.yahoo.com with NNFMP; 29 Aug 2009 18:52:39 -0000 X-Yahoo-Newman-Id: 837221.92071.bm@omp410.mail.mud.yahoo.com Received: (qmail 38498 invoked from network); 29 Aug 2009 18:52:39 -0000 Received: from unknown (HELO ?192.168.0.10?) (andy@68.120.231.134 with plain) by smtp106.sbc.mail.sp1.yahoo.com with SMTP; 29 Aug 2009 18:52:39 -0000 X-YMail-OSG: 9LX5n.oVM1lxamOfkZS9M4cSOW4tXb6zWcIofaynnMiwujw0MGTIpoTdAEK7SCkLIfwO5E_OJaVUloROpX9AN4CmXWm_DWMEUy8urPvcpbgV8RGJRM5ulfhLyECoJX8xsyMuT2eruZg3CMUNskDX0fuKy1ZXcEWtO0TrK5Jxv1Zs9aPQS7id2DH4I_rxAor84Rbz0YzQeyEeZ.A- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4A997902.1070105@netconfcentral.com> Date: Sat, 29 Aug 2009 11:52:50 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: "Joel M. Halpern" , NETCONF References: <4A9563BF.7060908@netconfcentral.com> <4A9942D1.3030003@netconfcentral.com> <4A994C94.7020600@netconfcentral.com> <20090829155832.GA24264@elstar.local> <4A9954F1.3040204@joelhalpern.com> <20090829182017.GA24348@elstar.local> In-Reply-To: <20090829182017.GA24348@elstar.local> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [Netconf] with-defaults terminology conflict 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, 29 Aug 2009 18:53:04 -0000 Juergen Schoenwaelder wrote: > On Sat, Aug 29, 2009 at 06:18:57PM +0200, Joel M. Halpern wrote: > >> For other values, I can not see any justification for not representing >> them. They need to be accessible to the management system. > > Accessible yes, but they are not part of the configuration. > >> The length issue seems to turn on who is processing this >> information. Machinery can deal with the length we are discussing. > > Making operational state by default is broken. It is wrong in most > cases to treat the MTU as config since what you want is likely the > value the kernel figured out for the piece of hardware you are > currently using. We are caught in circles. Here's the part I don't get. If the ifMtu is not config (i.e., config-stmt set to false), then you must be suggesting a YANG data modeler SHOULD use 2 objects, -- the ifOperMtu object and the ifAdminMtu object. That is a data model design issue. Even if that were the design choice, it seems to me that value of *both* leafs in the pair are required for the client to utilize the data model. If you want just 1 leaf, that is not part of the configuration, then you want a leaf that the client can never change. > > /js > Andy From andy@netconfcentral.com Sat Aug 29 12:04: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 300163A6936 for ; Sat, 29 Aug 2009 12:04:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.5 X-Spam-Level: X-Spam-Status: No, score=-2.5 tagged_above=-999 required=5 tests=[AWL=0.099, 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 cZQTwHQymgpT for ; Sat, 29 Aug 2009 12:04:32 -0700 (PDT) Received: from n13.bullet.mail.mud.yahoo.com (n13.bullet.mail.mud.yahoo.com [68.142.206.40]) by core3.amsl.com (Postfix) with SMTP id 2D36A3A6915 for ; Sat, 29 Aug 2009 12:04:32 -0700 (PDT) Received: from [68.142.200.224] by n13.bullet.mail.mud.yahoo.com with NNFMP; 29 Aug 2009 19:04:37 -0000 Received: from [68.142.201.248] by t5.bullet.mud.yahoo.com with NNFMP; 29 Aug 2009 19:04:37 -0000 Received: from [127.0.0.1] by omp409.mail.mud.yahoo.com with NNFMP; 29 Aug 2009 19:04:37 -0000 X-Yahoo-Newman-Id: 687195.82006.bm@omp409.mail.mud.yahoo.com Received: (qmail 44349 invoked from network); 29 Aug 2009 19:04:37 -0000 Received: from unknown (HELO ?192.168.0.10?) (andy@68.120.231.134 with plain) by smtp106.sbc.mail.sp1.yahoo.com with SMTP; 29 Aug 2009 19:04:37 -0000 X-YMail-OSG: LkZMPx8VM1mUUZwua55Gh8kUC5XHeqPENmsSTNli_ZEfK5_ZDdTtsQyD40V5uXBPHH0lrmLlWi90vbqfRUNmjaIys5ecUrdl4NB4kzh1s4me5aC_lko6bbjNXjbzNCMuauvrI_iksfXB.1wkza2UeWPka1Cd54wXiijDYa6uleYjPqZGyDXPgvvnxTx0bom30uNDRvI1lqiwTRk- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4A997B55.6030400@netconfcentral.com> Date: Sat, 29 Aug 2009 12:02:45 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: Andy Bierman , WashamFan , NETCONF References: <4A9563BF.7060908@netconfcentral.com> <4A9942D1.3030003@netconfcentral.com> <4A994C94.7020600@netconfcentral.com> <20090829155832.GA24264@elstar.local> <4A9956FF.50409@netconfcentral.com> <20090829182900.GC24348@elstar.local> In-Reply-To: <20090829182900.GC24348@elstar.local> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [Netconf] with-defaults terminology conflict 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, 29 Aug 2009 19:04:33 -0000 Juergen Schoenwaelder wrote: > On Sat, Aug 29, 2009 at 06:27:43PM +0200, Andy Bierman wrote: >> Juergen Schoenwaelder wrote: >>> On Sat, Aug 29, 2009 at 05:43:16PM +0200, Andy Bierman wrote: >>> >>>> So, here is the simplified version of what if filtered out (not returned): >>>> >>>> trim == leafs set to their YANG default-stmt value >>>> explicit == leafs that match the 'server-assigned data' definition >>>> report-all == nothing. nada. zip. every leaf is returned. nothing >>>> is filtered out. >>> Still wrong. Explicit does simply not have config leafes where there >>> is no config. There is no filtering with explicit. See also Phil's >>> email. We are going in circles. I guess we need help from the chairs >>> to move forward. >> I never said that, but I should have put 'instance of a leaf' everywhere. >> >> A 'leaf' is an object when referring to the schema tree. >> >> Since only instances of a leaf can possibly be retrieved >> with , , and , I thought it was >> obvious I was referring to instances of a leaf. Obviously not. > > As I said, we obviously need help from the chairs - we seem to talk > past each other for a while now and this is not effective. > maybe the co-Chairs are on vacation. Leafs omitted in PDUs: trim == leaf instances set to their YANG default-stmt value explicit == leaf instances that match the 'server-assigned data' definition report-all == none Is that clear enough? NETCONF capabilities cannot conflict with each other. One capability cannot change another one. If a server advertises the YANG module capability for the 'foo' module, then it MUST follow all the definitions for NETCONF content that the YANG language contains. We all agree on that. So advertisement of the 'with-defaults' or the 'acme-yang' capabilities is fine, but not if the server ALSO wants to advertise the YANG module capability. Pick one or the other. > /js > Andy From j.schoenwaelder@jacobs-university.de Sat Aug 29 14:14: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 DDCEB3A6CC5 for ; Sat, 29 Aug 2009 14:14:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.153 X-Spam-Level: X-Spam-Status: No, score=-2.153 tagged_above=-999 required=5 tests=[AWL=0.096, 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 7hfCdqhVyCLn for ; Sat, 29 Aug 2009 14:14:18 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 4279C3A6C6C for ; Sat, 29 Aug 2009 14:14:15 -0700 (PDT) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 2FF25C001E; Sat, 29 Aug 2009 23:14:22 +0200 (CEST) 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 RIYbCOmH0I1g; Sat, 29 Aug 2009 23:14:21 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 1828CC000D; Sat, 29 Aug 2009 23:14:20 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 55DD1C82E24; Sat, 29 Aug 2009 23:14:19 +0200 (CEST) Date: Sat, 29 Aug 2009 23:14:18 +0200 From: Juergen Schoenwaelder To: Andy Bierman Message-ID: <20090829211418.GA24525@elstar.local> Mail-Followup-To: Andy Bierman , WashamFan , NETCONF References: <4A9563BF.7060908@netconfcentral.com> <4A9942D1.3030003@netconfcentral.com> <4A994C94.7020600@netconfcentral.com> <20090829155832.GA24264@elstar.local> <4A9956FF.50409@netconfcentral.com> <20090829182900.GC24348@elstar.local> <4A997B55.6030400@netconfcentral.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4A997B55.6030400@netconfcentral.com> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: NETCONF Subject: Re: [Netconf] with-defaults terminology conflict 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: Sat, 29 Aug 2009 21:14:18 -0000 On Sat, Aug 29, 2009 at 09:02:45PM +0200, Andy Bierman wrote: > > maybe the co-Chairs are on vacation. > > Leafs omitted in PDUs: > > trim == leaf instances set to their YANG default-stmt value > explicit == leaf instances that match the 'server-assigned data' definition > report-all == none > > Is that clear enough? No, we need to wait that vacation ends. /js -- 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 Sun Aug 30 11:26:59 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 408793A6932 for ; Sun, 30 Aug 2009 11:26:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.003 X-Spam-Level: X-Spam-Status: No, score=-2.003 tagged_above=-999 required=5 tests=[AWL=0.043, 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 AHKZQnlshrh1 for ; Sun, 30 Aug 2009 11:26:58 -0700 (PDT) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id 7F3023A68B6 for ; Sun, 30 Aug 2009 11:26:58 -0700 (PDT) Received: from localhost (c213-100-167-236.swipnet.se [213.100.167.236]) by mail.tail-f.com (Postfix) with ESMTPSA id 74A2776C5A9; Sun, 30 Aug 2009 20:27:06 +0200 (CEST) Date: Sun, 30 Aug 2009 20:27:05 +0200 (CEST) Message-Id: <20090830.202705.263692013.mbj@tail-f.com> To: andy@netconfcentral.com From: Martin Bjorklund In-Reply-To: <4A994C94.7020600@netconfcentral.com> References: <4A9942D1.3030003@netconfcentral.com> <4A994C94.7020600@netconfcentral.com> X-Mailer: Mew version 6.0.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] with-defaults terminology conflict 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, 30 Aug 2009 18:26:59 -0000 Andy Bierman wrote: > with -- it is intended to be everything filtered out for 'explicit'. > > So, here is the simplified version of what if filtered out (not returned): > > trim == leafs set to their YANG default-stmt value > explicit == leafs that match the 'server-assigned data' definition server-assigned leafs would be returned in the explicit mode. The explicit mode returns all instances in the data store. > report-all == nothing. nada. zip. every leaf is returned. nothing > is filtered out. One way of viewing this is that it returns everything that have been set, and also all default values in effect, even though they do not really exist as instances in the data store. /martin