Subject: [Netconf] AUTH48 issues for 4741bis

From: Martin Bjorklund <[email-masked]>
Date: Tue, 07 Jun 2011 23:37:50 +0200 (CEST)

Hi,

4741bis is now in AUTH48, and we (the editors and the RFC editor)
found some issues.  Below are proposed changes for two non-editorial
clarifications.

In section 7.5, we forgot to add explicit text about what happens if
someone tries to take a lock on running while there's an ongoing
confirmed commit.  This was discussed in
http://www.ietf.org/mail-archive/web/netconf/current/msg05468.html.
A lock must be honored by the server, and a confirming commit might
timeout and change running.

OLD:

      A lock MUST NOT be granted if either of the following conditions
      is true:

      *  A lock is already held by any NETCONF session or another
         entity.

      *  The target configuration is <candidate>, it has already been
         modified, and these changes have not been committed or rolled
         back.

NEW:

      A lock MUST NOT be granted if either of the following conditions
      is true:

      *  A lock is already held by any NETCONF session or another
         entity.

      *  The target configuration is <candidate>, it has already been
         modified, and these changes have not been committed or rolled
         back. 

      *  The target configuration is <running>, and another NETCONF
         session has an ongoing confirmed commit (Section 8.4).

In Security Considerations, the last sentence of this paragraph is
bad:

OLD:

   In addition, operations on configurations could have unintended
   consequences if those operations are also not guarded by the global
   lock on the files or objects being operated upon.  For instance, a
   partially complete access list could be committed from a candidate
   configuration unbeknownst to the owner of the lock of the candidate
   configuration, leading to either an insecure or inaccessible device
   if the lock on the candidate configuration does not also apply to the
   <copy-config> operation when applied to it.

NEW:

   In addition, operations on configurations could have unintended
   consequences if those operations are also not guarded by the global
   lock on the files or objects being operated upon.  For instance, if
   the running configuration is not locked, a partially complete
   access list could be committed from a candidate configuration
   unbeknownst to the owner of the lock of the candidate
   configuration, leading to either an insecure or inaccessible
   device.

/martin

---

From: "Bert Wijnen \(IETF\)" <[email-masked]>
Date: Wed, 8 Jun 2011 00:19:42 +0200

As document shepherd, I believe that these are indeed good clarifications
adn so I propose to approve them.

Pls shout ASAP (in the next few days) if you see any issues.

Thanks,
Bert Wijnen
document shepherd

----- Original Message ----- 
From: "Martin Bjorklund" <[email-masked]>
To: <[email-masked]>
Sent: Tuesday, June 07, 2011 11:37 PM
Subject: [Netconf] AUTH48 issues for 4741bis

> _______________________________________________
> Netconf mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netconf

---

From: "Randy Presuhn" <[email-masked]>
Date: Tue, 7 Jun 2011 17:52:21 -0700

Hi -

Two comments, purely on the English.

> Sent: Tuesday, June 07, 2011 2:37 PM

The use of "either" sounds odd to me.  Using "any" instead of "either"
for the three-item list would make my ears happier.

>    configuration, leading to either an insecure or inaccessible

I find the new text confusing.  (Not that I understoof the old text.  :-)
It talks about both "a candidate" and "the candidate" (as did the old).
Do you intend "the candidate" to mean "that candidate", or possibly
something else?

Randy

---

From: Martin Bjorklund <[email-masked]>
Date: Wed, 08 Jun 2011 07:59:32 +0200 (CEST)

> Do you intend "the candidate" to mean "that candidate", or possibly

I think it should be "the candidate".

Searching for "a candidate" reveals:

8.3.4.1.  <commit>

   Description:

         When a candidate configuration's content is complete, the
         configuration data can be committed, publishing the data set to
         the rest of the device and requesting the device to conform to
         the behavior described in the new configuration.

I believe this should also be "the candidate".

/martin

---

From: "Bert (IETF) Wijnen" <[email-masked]>
Date: Fri, 10 Jun 2011 12:46:28 +0200

We only had the below comment from Randy, and we'll process it as suggested by MArtin.
Martin, pls go ahead and send the edits to the RFC-Editor.
Bert
document shepherd.

On 6/8/11 7:59 AM, Martin Bjorklund wrote:
> "Randy Presuhn"<[email-masked]>  wrote:
> 8.3.4.1.<commit>

---

From: "Bert (IETF) Wijnen" <[email-masked]>
Date: Fri, 10 Jun 2011 12:47:50 +0200

Martin, pls also include the below English language fix.

Bert
document shepherd

On 6/8/11 2:52 AM, Randy Presuhn wrote:
>> >  From: "Martin Bjorklund"<[email-masked]>
>> >  To:<[email-masked]>
>> >         *  The target configuration is<candidate>, it has already been
>> >         *  The target configuration is<candidate>, it has already been
>> >         *  The target configuration is<running>, and another NETCONF