Subject: Re: [Netconf] with-defaults clarification

From: WashamFan <[email-masked]>
Date: Tue, 04 Aug 2009 19:11:51 +0800

Hi,

----- Original Message -----
From: Andy Bierman <[email-masked]>
Date: Friday, July 31, 2009 1:07 am
Subject: [Netconf] with-defaults clarification
To: NETCONF <[email-masked]>

> Hi,
>  
>  I think the with-defaults draft should be clarified to
>  indicate that the <with-defaults> parameter is ignored
>  for <copy-config> 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" <with-defaults>?

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 <with-defaults>?

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

---

From: Andy Bierman <[email-masked]>
Date: Tue, 04 Aug 2009 06:50:37 -0700

> or comply with the <with-defaults>?

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".

Andy

---

From: WashamFan <[email-masked]>
Date: Wed, 05 Aug 2009 10:22:58 +0800

Hi,

>  Ignored means "has no affect".

The agent should handle default data regardless of ignoring <with-default> 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 Bierman <[email-masked]>
Date: Tue, 04 Aug 2009 20:14:33 -0700

> 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.

Andy

---

From: WashamFan <[email-masked]>
Date: Wed, 05 Aug 2009 12:41:22 +0800

Hi,

>  consistent with YANG rules.

Thanks. Could you point out which part of YANG spec dealing with this?

washam

---

From: Andy Bierman <[email-masked]>
Date: Wed, 05 Aug 2009 01:15:01 -0700

> Thanks. Could you point out which part of YANG spec dealing with this?

7.6.5 is one of them

Andy

---

From: Balazs Lengyel <[email-masked]>
Date: Wed, 05 Aug 2009 14:21:16 +0200

Hello Andy,
The draft says in chapter 2.5
"<copy-config> is only affected if the target of the operation is a
  URL."
Balazs

-- 
Balazs Lengyel                       Ericsson Hungary Ltd.
System Manager
ECN: 831 7320                        Fax: +36 1 4377792
Tel: +36-1-437-7320                  email: [email-masked]

---

From: Balazs Lengyel <[email-masked]>
Date: Wed, 05 Aug 2009 14:39:05 +0200

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 <rpc-reply> 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

---

From: Andy Bierman <[email-masked]>
Date: Wed, 05 Aug 2009 06:26:38 -0700

> "<copy-config> is only affected if the target of the operation is a

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 <with-defaults> value (if it wants)
to decide how <startup> 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 <startup> in
the first place?

Andy