Re: [Netconf] [Technical Errata Reported] RFC6241 (3821)

Andy Bierman <andy@yumaworks.com> Tue, 10 December 2013 16:56 UTC

Return-Path: <andy@yumaworks.com>
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E371A1AE1E1 for <netconf@ietfa.amsl.com>; Tue, 10 Dec 2013 08:56:02 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.977
X-Spam-Level:
X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NORMAL_HTTP_TO_IP=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CIc2fNUnUaQl for <netconf@ietfa.amsl.com>; Tue, 10 Dec 2013 08:56:00 -0800 (PST)
Received: from mail-qa0-f50.google.com (mail-qa0-f50.google.com [209.85.216.50]) by ietfa.amsl.com (Postfix) with ESMTP id E23D11AE1E2 for <netconf@ietf.org>; Tue, 10 Dec 2013 08:55:59 -0800 (PST)
Received: by mail-qa0-f50.google.com with SMTP id i13so3861704qae.2 for <netconf@ietf.org>; Tue, 10 Dec 2013 08:55:54 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=xW5euRgzhHSp07V4RbRlq8bArfMocE7/jA8YhYnf6lk=; b=XYWhc8/i34QXpkIQpwH9giO10RZUjiyCF8R6FGXoDD17N+mxHKi67x4LtgtCg8pxsr HSFBzSy5i4J/evVrfpfk8ylCLHgDRG1pdS+DpuhgPY+WjmBOAUYboYKe5kdsLN05oWT5 KgnQxWuI4/NgtMPzoBeJoy8xrXY7wL9naLrRwQXZZ32zESd+WNLkMFZodVfztdd68yvJ tZaW4gQDrHn5QRACoglYtTU9DiPiWVtLSVPiWLZARlvjJmuq7AufCg+mmdFQwIrx50+s meGgn2frQVxWmR8/oblF7KdU5YlheBBI7lY4Lh9DeC/S+sb+DA8Wknhg3qP0yJ/IU87N DrVA==
X-Gm-Message-State: ALoCoQkO6r6o5Z3g3z2T0yl1RDjf/8yjSJeri/j81ggidqWFYEp38YZEh0KJIsZraYWxUZDxRbVx
MIME-Version: 1.0
X-Received: by 10.224.60.69 with SMTP id o5mr46104200qah.92.1386694554337; Tue, 10 Dec 2013 08:55:54 -0800 (PST)
Received: by 10.140.48.75 with HTTP; Tue, 10 Dec 2013 08:55:54 -0800 (PST)
In-Reply-To: <cb13626ae792344d299ac437a00c906b@imap.plus.net>
References: <52A62972.4010001@bwijnen.net> <20131210.132819.2303764306420511964.mbj@tail-f.com> <52A7244A.4090006@bwijnen.net> <20131210.153651.1182516105923318005.mbj@tail-f.com> <CABCOCHQfbsz8AHY0SRs+TOcmARenvTQ2Nn_JtAkynexxh-wozw@mail.gmail.com> <cb13626ae792344d299ac437a00c906b@imap.plus.net>
Date: Tue, 10 Dec 2013 08:55:54 -0800
Message-ID: <CABCOCHQuruAH1ncpaj79iVViou0njkReKXhq=Kecejy6yD1jUg@mail.gmail.com>
From: Andy Bierman <andy@yumaworks.com>
To: Jonathan Hansford <Jonathan@hansfords.net>
Content-Type: multipart/alternative; boundary=001a11c3e488537de604ed30fcec
Cc: rob.enns@gmail.com, joelja@bogus.com, Netconf <netconf@ietf.org>
Subject: Re: [Netconf] [Technical Errata Reported] RFC6241 (3821)
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Network Configuration WG mailing list <netconf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/netconf>, <mailto:netconf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/netconf/>
List-Post: <mailto:netconf@ietf.org>
List-Help: <mailto:netconf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netconf>, <mailto:netconf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 10 Dec 2013 16:56:03 -0000

Hi,

The fact that it is not clear how confirmed commit works is an indication
of just how broken the shared candidate config is in NETCONF.
This is an artifact of CLI-based management, where nothing is locked,
and the management application is just an SSH terminal.

For programmatic applications, a shared scratchpad on the server is
a terrible design choice.  The NETCONF-EX draft fixes 1 or 2 of the
many problems (e.g., decouple confirmed-commit from candidate),
but it does not attempt to allow concurrent or independent transactions.

The persist-id supplies a long-lived lock on the <commit> operation,
but not against other sessions writing to the candidate (w/
edit/copy-config).

I found another clarification for confirmed commit.
Sec. 8.4.1, para 3:

   If the <persist> element is not given in the confirmed commit
   operation, any follow-up commit and the confirming commit MUST be
   issued on the same session that issued the confirmed commit.


Sec. 8.4.5.1:

     persist-id:

            Used to issue a follow-up confirmed commit or a confirming
            commit from any session, with the token from the previous
            <commit> operation.


There is no mention in 8.4.5.1 which error-tag to return if the persist-id
parameter is
missing or wrong. (in-use?).

Notice that 8.4.1 says "any follow-up commit" and 8.4.5.1 says "a follow-up
confirmed commit"?  This might make it unclear that any followup <commit>
without
the proper <persist-id> will be rejected by the server.


Andy




On Tue, Dec 10, 2013 at 8:05 AM, Jonathan Hansford
<Jonathan@hansfords.net>wrote:

>
>
> On 2013-12-10 15:59, Andy Bierman wrote:
>
> Hi,
> I don't think these 3 reports are corrections.
> They are editorial changes to the text.
> I don't agree that the new terminology added "sequence of confirmed
> commits"
> is correct.  There is just 1 netconf-confirmed-commit notification for
> start & complete
> sent out no matter how how many times the procedure is extended.
>  If the procedure ends with a cancel or timeout, there is only 1 original
> commit
> that is restored.  It is incorrect to think of this procedure as a series
> of
> confirmed commits.  A commit that extends the procedure is not treated
> the same as the commit that starts the procedure.
>
>  Are you saying that the initial commit of the sequence (the confirmed
> commit?) is restored should the procedure be cancelled or timeout? Surely
> the commit that is restored is the one that preceded the confirmed commit.
>  Jonathan
>
>  Andy
>
>
> On Tue, Dec 10, 2013 at 6:36 AM, Martin Bjorklund <mbj@tail-f.com>; wrote:
>
>> [fixing andy's address]
>>
>> "Bert Wijnen (IETF)" <bertietf@bwijnen.net>; wrote:
>> > Martin, did you mean to make this statement for all 3 reported errata,
>> > or just for 3821?
>>
>> All three.
>>
>> Editorial errata is fine with me.
>>
>>
>> /martin
>>
>>
>> >
>> > If anyone disagrees with Martin's assessment, pls speak up NOW.
>> >
>> > Thanks,
>> > Bert
>> >
>> > On 12/10/13 1:28 PM, Martin Bjorklund wrote:
>> > > "Bert Wijnen (IETF)" <bertietf@bwijnen.net>; wrote:
>> > >> We have a set of 3 new errata reported to RFC6241.
>> > >> See:
>> > >>
>> http://www.rfc-editor.org/errata_search.php?rfc=6241&rec_status=15&presentation=table
>> > >>
>> > >> We would like to hear from the authors/editors what their
>> > >> opinion is on the reported errata.
>> > >
>> > > I think the proposed text is fine, however I do not know if it
>> > > qualifies as an errata.  IMO it clarifies the description of
>> > > confirmed-commit, but the current text is not wrong.
>> > >
>> > >
>> > > /martin
>> > >
>> > >
>> >
>
>