Subject: [Netconf] AD review of draft-ietf-netconf-with-defaults-11

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Mon, 20 Sep 2010 16:30:31 +0200

I have reviewed draft-ietf-netconf-with-defaults-11 and I believe that
it is ready for IETF Last Call. I will send it soon to the IETF Last
Call. The comments below must be considered together with other comments
that may result from the IETF Last Call. The comments are divided into
Technical (T) and Editorial (E). 

T1. Section 1.3 

   'Often
   the default values are not interesting or specifically defined with a
   "reasonable" value, so that the management user does not have to
   handle them.'

What does 'specifically defined with a "reasonable" value' mean?

T2. Section 4.1

'o  SHOULD support the 'report-all' or 'report-all-tagged' defaults
      handling mode.'

What about the 'trim' and 'default' handling modes. Why SHOULD? MUST not
a server implementing the :with-defaults capability support at least one
of the defaults handling modes? 

T3. Section 4.3.  Conformance

   'Every NETCONF server SHOULD implement this capability.'

I assume that the SHOULD is because version 1.0 does not include this
capability. What about 4741bis and later - for these is not this a MUST?

E1. Section 1.1 - 
      'Schema default data
      MAY or may not be stored as part of a configuration datastore,
      depending on the basic mode used by a particular server.'

MAY needs not be capitalized here. 

E2. Please expand at first occurrence - CLI, SNMP, 

E3. Section 1.3

      The management application often needs a single, definitive and
      complete set of configuration values that determine how the a
      networking device works.

s/the a networking device/the netowrking device/

---

From: Andy Bierman <[email-masked]>
Date: Mon, 20 Sep 2010 08:18:54 -0700

> What does 'specifically defined with a "reasonable" value' mean?

I think it means there is a schema default value that is known,
and its value will not cause any problems in the network.
I agree the wording is strange.

> of the defaults handling modes? 

Sec. 2:

   A server MUST select one of the three basic modes defined in this
   section for handling default data.

The standard does not say which of the 3 modes MUST be supported.

Perhaps it is not clear that the original intent of the <with-defaults>
parameter was to return data with defaults -- as opposed to suppressing
the default leafs.  That MUST got watered down to a SHOULD.

It is possible for a server to claim conformance just by advertising
its basic-mode.  A <with-defaults> leaf set the the basic mode is supposed
to be accepted by the server, but this will not be of any use
to the client (pick 1 of 1 options).

> capability. What about 4741bis and later - for these is not this a MUST?

A 4741bis client can use 'merge' and 'remove' to edit the database,
and never be concerned with a default.  If the client chooses to
use 'create' and 'delete' (for no apparent reason), then the basic-mode
is useful to know wrt/ editing a leaf with a default value.

Even without this capability, the client can discover the basic-mode
of a server if it can attempt a 'no-op' edit on a default leaf, by
setting a missing default leaf to its default value, then retrieving it,
and finally deleting it.

The WG agreed on SHOULD, which is the right choice (IMO).

> MAY needs not be capitalized here. 

OK

> E2. Please expand at first occurrence - CLI, SNMP, 

OK

> s/the a networking device/the netowrking device/

OK -- remove 'a'

Andy

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Tue, 21 Sep 2010 14:16:11 +0200

Thanks for the answer.

See in-line. 

Regards,

Dan

> -----Original Message-----
> From: Andy Bierman [mailto:[email-masked]] 
> Sent: Monday, September 20, 2010 5:19 PM
> To: Romascanu, Dan (Dan)
> Cc: netconf
> Subject: Re: [Netconf] AD review of 
> draft-ietf-netconf-with-defaults-11
> 
> > Call. The comments below must be considered together with other 
> > comments that may result from the IETF Last Call. The comments are 
> > divided into Technical (T) and Editorial (E).
> > 
> > T1. Section 1.3
> > 
> >    'Often
> I think it means there is a schema default value that is 
> known, and its value will not cause any problems in the network.

Can you suggest other wording? 

> > What about the 'trim' and 'default' handling modes. Why 
> SHOULD? MUST 
> > not a server implementing the :with-defaults capability support at 
> > least one of the defaults handling modes?
> > 
> 
> Sec. 2:
> 

Bt at least one of them MUST be supported. Maybe this is a re-statement
of what already is stated in section 2, but I think that not having it
here is confusing. 

> 
> Perhaps it is not clear that the original intent of the 
> <with-defaults> parameter was to return data with defaults -- 
> as opposed to suppressing the default leafs.  That MUST got 
> watered down to a SHOULD.
> 
> It is possible for a server to claim conformance just by 
> advertising its basic-mode.  A <with-defaults> leaf set the 
> the basic mode is supposed to be accepted by the server, but 
> this will not be of any use to the client (pick 1 of 1 options).
> 
> A 4741bis client can use 'merge' and 'remove' to edit the 
> database, and never be concerned with a default.  If the 
> client chooses to use 'create' and 'delete' (for no apparent 
> reason), then the basic-mode is useful to know wrt/ editing a 
> leaf with a default value.
> 
> Even without this capability, the client can discover the 
> basic-mode of a server if it can attempt a 'no-op' edit on a 
> default leaf, by setting a missing default leaf to its 
> default value, then retrieving it, and finally deleting it.
> 

OK.