Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6CEEB1200B5 for ; Tue, 25 Jun 2019 15:57:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yumaworks-com.20150623.gappssmtp.com 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 Ib1ngRP92KZo for ; Tue, 25 Jun 2019 15:57:12 -0700 (PDT) Received: from mail-lf1-x12f.google.com (mail-lf1-x12f.google.com [IPv6:2a00:1450:4864:20::12f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F2C8112002E for ; Tue, 25 Jun 2019 15:57:11 -0700 (PDT) Received: by mail-lf1-x12f.google.com with SMTP id b11so178538lfa.5 for ; Tue, 25 Jun 2019 15:57:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=yLABkphDILmuS2hqMl4E0cp2XwV0DBF1WGekpCna43w=; b=l033yN6qUgpJnoV6LXagHCnNZqvzH2tsFd9FFBSOsoweI64fVqXu3WtmcIpIyoVhRV bLH+V/DTg67Vf7draKyyYSwq8yHXwyJ8TuqwmmNlTAycji6FJqza1zzFfK9e/chi8Bo/ SgepZngs2IrDbZz8P2YXMvZ60bZwcBwOF+mRPxCdKSseLpI2F7HpXEzJ2V/qTFHAPcB4 2zTCxf+o+0WoGmU2/N7hN+6e1jjq/y0vI3E5xL2wK4R/HTFFLRIlN9O5tWK+Kgl4kWyd TR+7jqhlXAC1Te39P8E7T5TQSo662YixovtDcWC1tc2+Xzyi6+Bun8VSV4iz59D12Q8N HQvg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=yLABkphDILmuS2hqMl4E0cp2XwV0DBF1WGekpCna43w=; b=ifCnfC1IhnEX+iZWu6xPzsYX2A1pGwrDWdBu6liKSD5d52UfXR4pV13dNaC/zqC6Ev sJcDptcRevnoz+jWQiW10ngQtBAsYvQPFOWSDmXFv7qZQ6q/Or1D3HtyNEbW98XLkKav XiYkbKuQJazQd9WgcLcVsbevhwy4rmFVGEArbZUaK/c/hvsgbq8PNngdqPGadn/LB0J7 lcUo8XiaLgXUKWhk1q39Ab1fpLzYjDtTkYTaf+63vnartw1J3nF0CJKGc253vFezU4yq 2wCk4+90yspNNwiFZSu4Os8Md8PVX8dhlSDHvwvYolx/IgHWThf1+pjkfVMQQIBpZYf4 IczQ== X-Gm-Message-State: APjAAAWqBuTMRaS55HVBSe4nev1FbxZQJxONtjvLMMcvkIZuwdOVfdJY 0r06yU4unCjrL/aaiAdvsedQ9Y/dy8NiN2DjwJCx1Q== X-Google-Smtp-Source: APXvYqzj6vzJb3cpCMTEBSHnDQzhpS+eXThKt0k1M+i8aclW9RT3czq+tTQOC4yG9LOJNngoH9ipMxCSbmtjOJgnA74= X-Received: by 2002:ac2:514b:: with SMTP id q11mr662080lfd.33.1561503429894; Tue, 25 Jun 2019 15:57:09 -0700 (PDT) MIME-Version: 1.0 References: <0100016aa75956af-70018fb1-15f8-4394-8ffd-4f4d5b2d7b3f-000000@email.amazonses.com> <0100016ab7a9af7e-cd7f776e-79e1-42a4-9c5d-d04aed0d8fa1-000000@email.amazonses.com> <76ED75C8-AA1A-4A03-A382-0DE834C914A1@gmail.com> <0100016abd77bfe3-88ae515a-d7f9-41c7-b627-9c51bdf16213-000000@email.amazonses.com> <884391D0-3F53-4F3D-BFB0-DD333D09507C@gmail.com> <00d101d51216$f807d120$e8177360$@hansfords.net> <3B2E5975-26B3-4310-B718-9D8D3F0B0DDA@gmail.com> <0100016b482fc5f4-caf4b52b-416a-438f-9c47-68df526fb9b7-000000@email.amazonses.com> <0100016b4bc86abb-d69f575f-c2e7-4ce9-93a5-047262cbff75-000000@email.amazonses.com> <0100016b4d55fbaf-7f6ae36b-0a00-4b10-a6c0-22fd0401a5e2-000000@email.amazonses.com> <3204AB2C-3B67-419A-851E-9BA8BEB2273A@gmail.com> In-Reply-To: <3204AB2C-3B67-419A-851E-9BA8BEB2273A@gmail.com> From: Andy Bierman Date: Tue, 25 Jun 2019 15:56:58 -0700 Message-ID: To: Mahesh Jethanandani Cc: "netconf@ietf.org" Content-Type: multipart/alternative; boundary="000000000000414196058c2dd940" Archived-At: Subject: Re: [netconf] RFC 6241 Ambiguity X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Jun 2019 22:57:16 -0000 --000000000000414196058c2dd940 Content-Type: text/plain; charset="UTF-8" Hi, these changes look OK to me. Andy On Tue, Jun 25, 2019 at 11:03 AM Mahesh Jethanandani < mjethanandani@gmail.com> wrote: > Summarizing the list of changes that we seem to have agreed upon: > > For the first set of changes in section 7.8 and 7.9, we seem to agree on > the original set of changes I had sent out earlier, which essentially > deferred the discussion of confirmed commit to section 8.4 of the RFC. The > second set of changes updates Section 8.4.1 to explain what happens to a > confirmed commit that includes a element. > > The highlights in the sections should enable identifying the changes. > > *CHANGE 1 START* > > OLD (as in original RFC 6241) > > *7.8* *. > * > > Description: Request graceful termination of a NETCONF session. > > When a NETCONF server receives a request, it will > gracefully close the session. The server will release any locks > and resources associated with the session and gracefully close any > associated connections. Any NETCONF requests received after a > request will be ignored. > > Positive Response: If the device was able to satisfy the request, an > is sent that includes an element. > > Negative Response: An element is included in the > if the request cannot be completed for any reason. > > Example: > > xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"> > > > > xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"> > > > > NEW > > *7.8* *. > * > > Description: Request graceful termination of a NETCONF session. > > When a NETCONF server receives a request, it will > gracefully close the session. The server will release any locks > and resources associated with the session and gracefully close any > associated connections. Any NETCONF requests received after a > request will be ignored. > > For details on what happens if a NETCONF server receives a > request while processing a confirmed commit, > please refer to Section 8.4 > . > > Positive Response: If the device was able to satisfy the request, an > is sent that includes an element. > > Negative Response: An element is included in the > if the request cannot be completed for any reason. > > Example: > > xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"> > > > > xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"> > > > > OLD (as in original RFC 6241). > > *7.9* *. * > > Description: Force the termination of a NETCONF session. > > When a NETCONF entity receives a request for an > open session, it will abort any operations currently in process, > release any locks and resources associated with the session, and > close any associated connections. > > If a NETCONF server receives a request while > processing a confirmed commit (Section 8.4 > ), it MUST restore the > configuration to its state before the confirmed commit was issued. > > Otherwise, the operation does not roll back > configuration or other device state modifications made by the > entity holding the lock. > > Parameters: > > session-id: Session identifier of the NETCONF session to be > terminated. If this value is equal to the current session ID, > an "invalid-value" error is returned. > > Positive Response: If the device was able to satisfy the request, an > is sent that includes an element. > > Negative Response: An element is included in the > if the request cannot be completed for any reason. > > > Example: > > xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"> > > 4 > > > > xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"> > > > > NEW > > *7.9* *. * > > Description: Force the termination of a NETCONF session. > > When a NETCONF entity receives a request for an > open session, it will abort any operations currently in process, > release any locks and resources associated with the session, and > close any associated connections. > > For details on what happens if a NETCONF server receives a > request while processing a confirmed commit, > please refer to Section 8.4 > . > > Otherwise, the operation does not roll back > configuration or other device state modifications made by the > entity holding the lock. > > Parameters: > > session-id: Session identifier of the NETCONF session to be > terminated. If this value is equal to the current session ID, > an "invalid-value" error is returned. > > Positive Response: If the device was able to satisfy the request, an > is sent that includes an element. > > Negative Response: An element is included in the > if the request cannot be completed for any reason. > > > Example: > > xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"> > > 4 > > > > xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"> > > > > *CHANGE 1 END* > > *CHANGE 2 START* > The following paragraph in Section 8.4.1 would be modified. > > OLD: > > If the device reboots for any reason before the confirm timeout > expires, the server MUST restore the configuration to its state > before the confirmed commit was issued. > > > NEW: > > If the device reboots for any reason before the confirm timeout > expires, the server MUST restore the configuration to its state > before the confirmed commit was issued, unless the confirmed commit > also included a element, in which case the server MAY continue > the confirmed commit procedure. > > *CHANGE 2 END* > > Finally, looking at the current set of Errata that are already open > against the RFC, we (the chairs) believe that Errata number 5397 should be > deleted and (a new Errata with these contents) be posted. This is being > done to avoid stacking one Errata on top of another. > > Unless there is objection to these changes within the next two weeks, we > will proceed with submitting them to the RFC Editor. > > On Jun 12, 2019, at 2:47 PM, Andy Bierman wrote: > > Hi, > > This is the new text in question: > It appears your intent is (c) since there is no mention at all what > happens if > was included. The text just says what does not happen in this > case. > > >>> If the device reboots for any reason before the confirm timeout >>> expires, the server MUST restore the configuration to its state >>> before the confirmed commit was issued, unless the confirmed commit >>> also included a element. >>> >> > > How about adding at the end: > > OLD: > > element. > > NEW: > > element, in which case the server MAY continue the confirmed commit > procedure. > > > Andy > > > > On Wed, Jun 12, 2019 at 1:16 PM Kent Watsen wrote: > >> >> Hi Andy, >> >> I object to changing RFC 6241 with an Errata if it attempts to enforce >> protocol behavior >> that the original RFC does not actually specify. (c) is correct for an >> Errata because the original RFC >> is under-specified. Or perhaps: (d) 'persist' MAY span reboots >> >> >> It sounds like we're in agreement. Are you objecting to something I >> wrote in particular? >> >> Kent // contributor >> >> >> > Mahesh Jethanandani > mjethanandani@gmail.com > > > > _______________________________________________ > netconf mailing list > netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf > --000000000000414196058c2dd940 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi,

these changes look OK to= me.

Andy


On Tue, Jun 25, 2019 at 11= :03 AM Mahesh Jethanandani <m= jethanandani@gmail.com> wrote:
Summarizing= the list of changes that we seem to have agreed upon:

F= or the first set of changes in section 7.8 and 7.9, we seem to agree on the= original set of changes I had sent out earlier, which essentially deferred= the discussion of confirmed commit to section 8.4 of the RFC. The second s= et of changes updates Section 8.4.1 to explain what happens to a confirmed = commit that includes a <persist> element.

Th= e highlights in the sections should enable identifying the changes.

CHANGE 1 START

OLD (as in orig= inal RFC 6241)

7.8.=C2=A0 = <close-session>

=C2=A0=C2=A0= Description:=C2=A0 Request graceful termination of a NETCONF session.

=C2=A0 =C2=A0 =C2=A0 When a NETCONF server= receives a <close-session> request, it will
=C2=A0 =C2=A0 = =C2=A0 gracefully close the session.=C2=A0 The server will release any lock= s
=C2=A0 =C2=A0 =C2=A0 and resources associated with the session an= d gracefully close any
=C2=A0 =C2=A0 =C2=A0 associated connections.= =C2=A0 Any NETCONF requests received after a
=C2=A0 =C2=A0 =C2=A0 &= lt;close-session> request will be ignored.

=C2=A0=C2=A0 Positive Response:=C2=A0 If the device was able to sat= isfy the request, an
=C2=A0 =C2=A0 =C2=A0 <rpc-reply> is sent= that includes an <ok> element.

= =C2=A0=C2=A0 Negative Response:=C2=A0 An <rpc-error> element is inclu= ded in the
=C2=A0 =C2=A0 =C2=A0 <rpc-reply> if the request ca= nnot be completed for any reason.

=
=C2= =A0=C2=A0 Example:

=C2=A0=C2=A0 =C2=A0= <rpc message-id=3D"101"
=C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 xmlns=3D"urn:ietf:params:xml:ns:netconf:base:1.0">
=C2=A0=C2=A0 =C2=A0 =C2=A0 <close-session/>
=C2=A0=C2=A0 = =C2=A0 </rpc>

=C2=A0=C2=A0 =C2= =A0 <rpc-reply message-id=3D"101"
=C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 xmlns=3D"urn:ietf:params:xml:ns:netconf:base:1.0"&= gt;
=C2=A0=C2=A0 =C2=A0 =C2=A0 <ok/>
=C2=A0=C2=A0 = =C2=A0 </rpc-reply>

NEW
7.8.=C2=A0 <close-session>
=
=C2=A0=C2=A0 Description:=C2=A0 Request graceful termina= tion of a NETCONF session.

=C2=A0 =C2= =A0 =C2=A0 When a NETCONF server receives a <close-session> request, = it will
=C2=A0 =C2=A0 =C2=A0 gracefully close the session.=C2=A0 Th= e server will release any locks
=C2=A0 =C2=A0 =C2=A0 and resources = associated with the session and gracefully close any
=C2=A0 =C2=A0 = =C2=A0 associated connections.=C2=A0 Any NETCONF requests received after a<= /span>
=C2=A0 =C2=A0 =C2=A0 <close-session> request will be ignored.=

=C2=A0 =C2=A0 =C2=A0=C2=A0For details on what happe= ns if a NETCONF server receives a=C2=A0
=C2=A0= =C2=A0 =C2=A0 <close-session> request while processing a confirmed c= ommit,
=C2=A0 =C2=A0 =C2=A0 please refer to=C2= =A0Section 8.4.

=C2=A0=C2=A0 Positive Response:=C2=A0 If the d= evice was able to satisfy the request, an
=C2=A0 =C2=A0 =C2=A0 <= rpc-reply> is sent that includes an <ok> element.

=C2=A0=C2=A0 Negative Response:=C2=A0 An <rpc-error= > element is included in the
=C2=A0 =C2=A0 =C2=A0 <rpc-reply&= gt; if the request cannot be completed for any reason.

=C2=A0=C2=A0 Example:

<= /div>
=C2=A0=C2=A0 =C2=A0 <rpc message-id=3D"101"
=C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 xmlns=3D"urn:ietf:params:xml:ns:netconf:ba= se:1.0">
=C2=A0=C2=A0 =C2=A0 =C2=A0 <close-session/><= /span>
=C2=A0=C2=A0 =C2=A0 </rpc>
=C2=A0=C2=A0 =C2=A0 <rpc-reply message-id=3D"101"
= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 xmlns=3D"urn:ietf:params:xml:ns:net= conf:base:1.0">
=C2=A0=C2=A0 =C2=A0 =C2=A0 <ok/>
=C2=A0=C2=A0 =C2=A0 </rpc-reply>
<= br>
O= LD (as in original RFC 6241).


<= /div>
=C2=A0=C2=A0 Description:=C2=A0 Force the termination of a NETCONF session= .

=C2=A0 =C2=A0 =C2=A0 When a NETCONF = entity receives a <kill-session> request for an
=C2=A0 =C2=A0= =C2=A0 open session, it will abort any operations currently in process,
= =C2=A0 =C2=A0 =C2=A0 release any locks and resources associated with = the session, and
=C2=A0 =C2=A0 =C2=A0 close any associated connecti= ons.

=C2=A0 =C2=A0 =C2=A0 If a NETCONF= server receives a <kill-session> request while
=C2=A0 =C2=A0 =C2=A0= configuration to its state before the confirmed commit was issued.<= /div>

=C2=A0 =C2=A0 =C2=A0 Otherwise, the <kill-= session> operation does not roll back
=C2=A0 =C2=A0 =C2=A0 confi= guration or other device state modifications made by the
=C2=A0 =C2= =A0 =C2=A0 entity holding the lock.

= =C2=A0=C2=A0 Parameters:

=C2=A0 =C2=A0= =C2=A0 session-id:=C2=A0 Session identifier of the NETCONF session to be
=C2=A0=C2=A0 =C2=A0 =C2=A0 =C2=A0 terminated.=C2=A0 If this value is= equal to the current session ID,
=C2=A0=C2=A0 =C2=A0 =C2=A0 =C2=A0= an "invalid-value" error is returned.

=C2=A0=C2=A0 Positive Response:=C2=A0 If the device was able to = satisfy the request, an
=C2=A0 =C2=A0 =C2=A0 <rpc-reply> is s= ent that includes an <ok> element.
=C2=A0=C2=A0 Negative Response:=C2=A0 An <rpc-error> element is in= cluded in the
=C2=A0 =C2=A0 =C2=A0 <rpc-reply> if the request= cannot be completed for any reason.


=C2=A0=C2=A0 Example:
<= /span>
=C2=A0=C2=A0 =C2=A0 <rpc message-id=3D"101"=
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 xmlns=3D"urn:ietf:params:xml:ns:n= etconf:base:1.0">
=C2=A0=C2=A0 =C2=A0 =C2=A0 <kill-sessi= on>
=C2=A0=C2=A0 =C2=A0 =C2=A0 =C2=A0 <session-id>4</se= ssion-id>
=C2=A0=C2=A0 =C2=A0 =C2=A0 </kill-session>
=C2=A0=C2=A0 =C2=A0 </rpc>

= =C2=A0=C2=A0 =C2=A0 <rpc-reply message-id=3D"101"
=
=C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 xmlns=3D"urn:ietf:params:xml:ns:netcon= f:base:1.0">
=C2=A0=C2=A0 =C2=A0 =C2=A0 <ok/><= /div>
=C2=A0=C2=A0 =C2=A0 </rpc-reply>

=
NEW<= /div>

7.9.=C2=A0 <kill-session&= gt;

=C2=A0=C2=A0 Description:=C2= =A0 Force the termination of a NETCONF session.

=C2=A0 =C2=A0 =C2=A0 When a NETCONF entity receives a <kill-se= ssion> request for an
=C2=A0 =C2=A0 =C2=A0 open session, it will= abort any operations currently in process,
=C2=A0 =C2=A0 =C2=A0 re= lease any locks and resources associated with the session, and
=
=C2= =A0 =C2=A0 =C2=A0 close any associated connections.

=C2=A0 =C2= =A0 =C2=A0=C2=A0For details on what happens if a NETCONF serve= r receives a=C2=A0
=C2=A0 =C2=A0 =C2=A0 <ki= ll-session> request while processing a confirmed commit,
=C2=A0 =C2=A0 =C2=A0 please refer to=C2=A0Section 8.4.

=C2=A0 =C2=A0 =C2=A0 Otherwise, the <kill-session> operation d= oes not roll back
=C2=A0 =C2=A0 =C2=A0 configuration or other devic= e state modifications made by the
=C2=A0 =C2=A0 =C2=A0 entity holdi= ng the lock.

=C2=A0=C2=A0 Parameters:<= /span>

=C2=A0 =C2=A0 =C2=A0 session-id:=C2=A0= Session identifier of the NETCONF session to be
=C2=A0=C2=A0 =C2= =A0 =C2=A0 =C2=A0 terminated.=C2=A0 If this value is equal to the current s= ession ID,
=C2=A0=C2=A0 =C2=A0 =C2=A0 =C2=A0 an "invalid-value= " error is returned.

=C2=A0=C2=A0= Positive Response:=C2=A0 If the device was able to satisfy the request, an=
=C2=A0 =C2=A0 =C2=A0 <rpc-reply> is sent that includes an &l= t;ok> element.

=C2=A0=C2=A0 Negativ= e Response:=C2=A0 An <rpc-error> element is included in the
= =C2=A0 =C2=A0 =C2=A0 <rpc-reply> if the request cannot be completed f= or any reason.

=
= =C2=A0=C2=A0 Example:

=C2=A0=C2= =A0 =C2=A0 <rpc message-id=3D"101"
=C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 xmlns=3D"urn:ietf:params:xml:ns:netconf:base:1.0&quo= t;>
=C2=A0=C2=A0 =C2=A0 =C2=A0 <kill-session>
=
=C2= =A0=C2=A0 =C2=A0 =C2=A0 =C2=A0 <session-id>4</session-id>
=C2=A0=C2=A0 =C2=A0 =C2=A0 </kill-session>
=C2=A0=C2=A0 = =C2=A0 </rpc>

=C2=A0=C2=A0 =C2= =A0 <rpc-reply message-id=3D"101"
=C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 xmlns=3D"urn:ietf:params:xml:ns:netconf:base:1.0"&= gt;
=C2=A0=C2=A0 =C2=A0 =C2=A0 <ok/>
=C2=A0=C2=A0 = =C2=A0 </rpc-reply>

CHANGE 1 END=

CHANGE 2 START
The following paragraph in= Section 8.4.1 would be modified.

OLD:

=C2=A0= =C2=A0 If the device reboots for any reason before the confirm timeout
=C2=A0=C2=A0 expires, the server MUST restore the configuration to its = state
=C2=A0=C2=A0 before the confirmed commit was issued.


NEW:

=C2=A0=C2=A0 If the device = reboots for any reason before the confirm timeout
=C2=A0=C2=A0 expi= res, the server MUST restore the configuration to its state
=C2=A0= =C2=A0 before the confirmed commit was issued,=C2=A0unless the confirmed commit=C2=A0
=C2=A0=C2=A0 also included a <persist> element, in which cas= e the server MAY continue
=C2=A0 =C2=A0<= /span>the confirmed commit procedure.<= /span>

= CHANGE 2 END

Finally, looking at the cu= rrent set of Errata that are already open against the RFC, we (the chairs) = believe that Errata number 5397 should be deleted and (a new Errata with th= ese contents) be posted. This is being done to avoid stacking one Errata on= top of another.

Unless there is object= ion to these changes within the next two weeks, we will proceed with submit= ting them to the RFC Editor.

O= n Jun 12, 2019, at 2:47 PM, Andy Bierman <andy@yumaworks.com> wrote:

Hi,

This is the new text in question:
It= appears your intent is (c) since there is no mention at all what happens i= f
<persist> was included.=C2=A0 The text just says what doe= s not happen in this case.


=C2=A0=C2=A0=C2=A0= If the device reboots for any reason before the confirm timeout
=C2=A0=C2=A0=C2=A0expires, the server MUST restore the configuration to its= state
=C2=A0=C2=A0=C2=A0before the confirmed commit was issued,= =C2=A0unless the confirmed commit=C2=A0
=C2=A0=C2=A0=C2=A0also included a <persist> eleme= nt.


How a= bout adding at the end:

OLD:

<= div>element.

NEW:

element= , in which case the server MAY continue the confirmed commit procedure.


Andy
=C2=A0

On Wed, Jun 12, 2019 at 1:16 PM Kent Watsen <kent+ietf@watsen.net> wrote:

Hi Andy,

I object to changing RFC 6241 = with an Errata if it attempts to enforce protocol behavior
that t= he original RFC does not actually specify.=C2=A0 (c) is correct for an Erra= ta because the original RFC
is under-specified.=C2=A0 Or perhaps:= (d) 'persist' MAY span reboots

It sounds like we're in agreement.=C2=A0 Are you o= bjecting to something I wrote in particular?

Kent= // contributor
_______________________________________________
netconf mailing list
netconf@ietf.org<= br> https://www.ietf.org/mailman/listinfo/netconf
--000000000000414196058c2dd940--