Subject: [netmod] [[email-masked]: RE: ip interface configuration data model review]

From: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 26 Mar 2012 11:56:08 +0200

Hi,

I am forwarding a review by Dave Thaler who is not on this list.

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1, 28759 Bremen, Germany
Fax:   +49 421 200 3103         <http://www.jacobs-university.de/>

Subject: RE: ip interface configuration data model review
From: Dave Thaler <[email-masked]>
To: Juergen Schoenwaelder <[email-masked]>, Margaret Wasserman <[email-masked]>
Cc: Brian Haberman <[email-masked]>, David Kessens <[email-masked]>, Martin Bjorklund <[email-masked]>
Date: Sat, 24 Mar 2012 18:46:27 +0000

My comments are now in marked up PDF copies at
http://research.microsoft.com/~dthaler/draft-ietf-netmod-interfaces-cfg-03.pdf
http://research.microsoft.com/~dthaler/draft-ietf-netmod-ip-cfg-02.pdf
http://research.microsoft.com/~dthaler/draft-ietf-netmod-routing-cfg-01.pdf

I won't have time to reformulate my feedback as text email, but the above 
links can be posted to the netmod list.  I'm not a member of the list though.
Do you want to post a message to the list with the links or want me to 
(which you'll then have to approve)?

-Dave

> -----Original Message-----
> From: Juergen Schoenwaelder [mailto:j.schoenwaelder@jacobs-
> university.de]
> Sent: Thursday, February 09, 2012 11:24 AM
> To: Dave Thaler; Margaret Wasserman
> Cc: Brian Haberman; David Kessens; Martin Bjorklund
> Subject: Re: ip interface configuration data model review
> 
> Margaret and Dave,
> 
> thanks very much for volunteering to help us with this document. The
> primary I-D is http://tools.ietf.org/html/draft-ietf-netmod-ip-cfg-02.
> It builds on a generic interfaces configuration model defined in
> http://tools.ietf.org/html/draft-ietf-netmod-interfaces-cfg-03. The interfaces
> document is in WG last call and should be relatively stable. Both documents
> are fairly short - our goal is to get the essentials right and not to include
> everything that might be possible in the first version. For the IP interface
> configuration model in particular, we need to sort out what to include and
> what we can leave out and perhaps you can help us with that. Note that
> routing specific configuration is expected to go into a separate IP routing data
> model, http://tools.ietf.org/html/draft-ietf-netmod-routing-cfg-01.
> 
> I am attaching an open issues list that Martin Bjorklund (the editor of draft-
> ietf-netmod-ip-cfg-02) maintains. I think it is best if discussions go to the
> NETMOD mailing list.
> 
> /js
> 
> On Wed, Feb 08, 2012 at 05:17:37PM -0500, Brian Haberman wrote:
> > Juergen,
> >      Margaret Wasserman and Dave Thaler are willing to help with
> > reviews.  Please let them know what drafts they should be reading
> > within NETMOD.
> >
> > Regards,
> > Brian
> 
> --
> Juergen Schoenwaelder           Jacobs University Bremen gGmbH
> Phone: +49 421 200 3587         Campus Ring 1, 28759 Bremen, Germany
> Fax:   +49 421 200 3103         <http://www.jacobs-university.de/>

---

From: Martin Bjorklund <[email-masked]>
Date: Thu, 29 Mar 2012 08:48:20 +0200 (CEST)

Hi Dave,

Thank you very much for your review, it is very helpful!

I have made changes according to your comments in most cases.  Below
are my comments on some of the issues:

draft-ietf-netmod-interfaces-cfg
================================

DT5:

>>  leaf name { ...
>>    This leaf MAY be mapped to ifName by an implementation.  Such an
>>    implementation MAY restrict the allowed values for this leaf so
>>    that it matches the restrictions of ifName.

> Whats the alternative? That is, if an implementation maps it to
> ifName, what else could it do besides restricting the allowed
> values? If it doesn’t restrict, I don’t see how it could be mapped
> to ifName.

The alternative would be up to the implementation.  For example, it
could do some kind of transform, or it could simply put a zero-length
string in ifName for this interface.

draft-ietf-netmod-ip-cfg
========================

DT4:

>   There appear to be some configurable, non-routing- related, objects
>   in the IP-MIB that are not configurable via this document. I would
>   expect there to be an explanation of why they were omitted:
> 
>   ipAddressStatus (which can be used to mark a static address as
>       deprecated without deleting it),

Is this really a configuration parameter, i.e. saved to non-volatile
storage?  If it is, I assume only a subset of the values can be
written?  Also, if the new value can be written probably depends on
the current value (e.g., I assume I cannot make a 'duplicate' address
'preferred'?

> ipDefaultTTL
> ipv6IpDefaultHopLimit

In RFC 4862, "CurHopLimit" is listed as a per-interface variable.
There is no configuration variable defined in 4862.

> ipNetToPhysicalAddressTable

This table it defined to not be stored in non-volatile memory, so it
wouldn't map to config here.

---------------

DT9:

> dup-addr-detect-transmits is NOT just for "autoconfiguration", it
> controls DAD for manually configured static addresses too. RFC 4862
> states: "The test should individually be performed on all addresses
> obtained manually, via stateless address autoconfiguration, or via
> DHCPv6."

Right...

DT11:

> Since the intent is to configure parameters related to addressing,
> not just the addresses themselves, there appears to be a couple more
> things missing: See TEMP_VALID_LIFETIME and TEMP_PREFERRED_LIFETIME

...so I moved dup-addr-detect-transmits one level up, and added
parameters from RFC 4941:

         +--rw ipv6
            ...
            +--rw dup-addr-detect-transmits?   uint32
            +--rw autoconf
               +--rw create-global-addresses?        boolean
               +--rw create-temporary-addressed?     boolean
               +--rw temporary-valid-lifetime?       uint32
               +--rw temporary-preferred-lifetime?   uint32

Does this seem to be correct?

/martin