Subject: Re: [BEHAVE] [Softwires] Early MIB doctor review of draft-ietf-softwire-dslite-mib-03

From: "Fuyu (Eleven)" <[email-masked]>
Date: Wed, 6 Nov 2013 09:41:51 +0000

Hi, Dave,

Thanks a lot  for your review. We have revised an updated version based on your comments as draft-ietf-softwire-dslite-mib-04.  Please see my reply below:

Best regards,

Yu

From: [email-masked] [mailto:[email-masked]] On Behalf Of Dave Thaler
Sent: Saturday, October 05, 2013 8:43 AM
To: [email-masked]
Cc: Benoit Claise; [email-masked]
Subject: [Softwires] Early MIB doctor review of draft-ietf-softwire-dslite-mib-03

Benoit asked me to do an early MIB doctor review of this document.  My
full comments are in the marked up copy at
http://research.microsoft.com/~dthaler/draft-ietf-softwire-dslite-mib-03.pdf
(there’s also a .docx version if you replace the .pdf extension with .docx)

I’ve also cc’ed the behave WG on this mail since many of my comments concern
the relationship between draft-ietf-behave-nat-mib  and the translation parts of
this draft.

A short summary of the high level issues in my review is:

1)      The doc is not aligned with draft-ietf-behave-nat-mib.  It currently continues

some practices that we’re trying to deprecate as discussed in section 3.1 of

draft-ietf-behave-nat-mib.

[Yu]: All objects related to The NAT-MIB have been updated according to the draft-ietf-behave-nat-mib.

2)      Boilerplate needs to be updated to match latest MIB boilerplate (see inline

comments for pointers).

[Yu]: It has already been updated in the 04 version.

3)      Any InetPortNumber object allowing 0 needs to explain what 0 means in that

object, as required by RFC 4001.

[Yu]: The InetPortNumber objects allowing 0 in the DS-Lite MIB have been deleted in the updated version.

4)      Draft currently requires write support in all implementations.  Recommend

having a read-only compliance statement since nowadays many folks don’t

want write support via MIBs.

[Yu]: All the object requires write support in the 03 version had been defined to ”read-only” as recommend in new version except the

         object “dsliteAFTRAlarmConnectNumber”. The object indicates the threshold of the tunnel number of which can be connected to the AFTR.

        It is always set by the network manager for the performance consideration.

-Dave