Message info
 
To:dthaler@microsoft.com From:Martin Bjorklund Subject:Re: [netmod] [dthaler@microsoft.com: RE: ip interface configuration data model review] 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 doesnt restrict, I dont 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
_______________________________________________
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod