Subject: Re: [Netconf] Comments on draft-badra-netconf-rfc5539bis-02.txt

From: Alan Luchuk <[email-masked]>
Date: Mon, 1 Oct 2012 13:38:06 -0400 (EDT)

Hello,

>> >> > o  YANG module
>> >> >
>> >> > o  list cert-map
>> >> > 
>> >> >   Instead of using an integer key, I suggest you use an ordered-by
>> >> >   user list with an arbitratry string as key.   This use case is why
>> >> >   ordered-by user lists exist.
>> >> > 
>> >> > 
>> >> > o leaf map-type {
>> >> > 
>> >> >   Instead of enumerating all different combinations, I suggest you use
>> >> >   an ordered-by user leaf-list.  Also, I think the following structure
>> >> >   would be more natural:
>> >> > 
>> >> >     choice map-type {
>> >> >       leaf specified {
>> >> >         type nacm:user-name-type;  // note the new type
>> >> >         // replaces your "data" leaf
>> >> >       }
>> >> >       leaf-list from-certificate {
>> >> >         type enumeration {
>> >> >           enum rfc822Name;
>> >> >           enum dNSName;
>> >> >           enum ipAddress;
>> >> >         }
>> >> >         ordered-by user;
>> >> >       }
>> >> >     }
>> >> > 
>> >> >   Then you can use for example:
>> >> > 
>> >> >     <specified>bob</specified>
>> >> > 
>> >> >   or
>> >> > 
>> >> >     <from-certificate>dnsName</from-certificate>
>> >> >     <from-certificate>rfc822Name</from-certificate>
>> >> 
>> >> I prefer to leave the YANG objects as proposed.
>> >
>> >Can you provide some motivation for this?  To me, this looks like a
>> >rather direct translation from a MIB structure (which the document
>> >also says it is).  
>> 
>> That's pretty much the reason.  I prefer making the newer standard 
>> similar to the existing standard to ease the transition to the newer 
>> standard.
>
>I am not sure I agree with this statement in general, but even with
>the proposed changes to the data model, it is really very similar to
>the MIB.
>
>
>/martin
>

I have been hoping for a few additional voices on the WG mailing list so
there would be a clear preference about which way to resolve this.

It seems there is reasonable consensus about most of the recent proposed
text changes.  I propose incorporating these into the draft, and continuing
the discussion about this last issue.

Regards,
--Alan

---

From: Andy Bierman <[email-masked]>
Date: Mon, 1 Oct 2012 10:59:38 -0700

Hi,

Few comments:
  1) I like the new 'map-type' proposal better than what is
      in the draft

  2) there should be 1 top level /netconf-config container
      and then /netconf-config/tls.  Then the 2 containers
      in this module would be child nodes of tls.

  3) The charter says:
       1. Advance NETCONF over TLS to be in-line with NETCONF 1.1
       (i.e., update RFC 5539).

      This document seems to go way beyond the charter of aligning
      with base:1.1 vs. base:1.0.

      Which changes (if any) are directly related to changes in the NETCONF
      protocol?  Why is configuration of TLS part of this charter?

Andy

On Mon, Oct 1, 2012 at 10:38 AM, Alan Luchuk <[email-masked]> wrote:

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