Subject: [MEXT] AD review of draft-ietf-mext-nemo-mib

From: Jari Arkko <[email-masked]>
Date: Tue, 03 Jun 2008 17:21:29 -0400

Here are the results of my review. I believe the documents needs one
additional editing round, as well as a few additional reviews to make
sure everything is right.

All the issues below are relatively small, but the fact that many
of these things were missed means that additional eyes are needed
on the document.

Here are the details:

- Remove Counter64, because it is not used

- Replace [email-masked] with [email-masked]

- Update copyright notice to 2008

- Update revision string

- nemoRegisteredUpTime: Do you count only the current location and
  registration? Please specify.

- nemoRegHomeAgentAddress: The text says: "The home agent address of
  the mobile router which was used in the last accepted registration."
  I cannot parse this statement. Did you mean to say "The home agent
  address used in the last accepted registration sent by the mobile
  router."? A similar change would be needed for nemoRegHomeAddress,
  nemoRegCareofAddress.

- nemoRegHomeAddressPrefixLength: The text says: "The prefix length of
  the home address that the mobile router is using for roaming."
  What does roaming have to do with this? Just say "The prefix length
  of the home address for the mobile router."

- nemoActiveEgressIfIndex: s/current active/currently active/.

- nemoHomeRegRetryCount and nemoHomeRegRetryDelay appear to implement
  a BU retransmission model that is based on a maximum number of
  attempts, with fixed time between them. This is in violation of
  RFC 3775, Section 11.8.

- nemoRegisterConnectedPrefixes: The term "connected prefix" does not
  appear in RFC 3963 or RFC 4885. Please provide a reference or define
  what the semantics of this object are.

- nemoBindingCacheTable: It says: "This table models the Binding Cache
  that includes NEMO related information and is maintained by the
  mobile router." This is obviously wrong, as it is the home agent
  that maintains this information. More generally, I'm concerned that
  similar errors have crept into many of the description fields in
  the document. It needs better review.

- nemoBindingAckNotHomeRegn, nemoBindingRegTypeChanged: why is
  the naming different (BindingAck vs. BindingReg)?

- nemoBindingAckNotHomeRegn, nemoBindingRegTypeChanged, etc:
  why is there no nemoBindingAckOtherError to count the number
  of errors not classified in the MIB? Remember that we keep
  adding new error codes.

- nemoMovedFNtoFN: this object should clarify that movement
  is defined as movement in layer 3, i.e., a different
  care of address was configured. Movements at layer 2
  may result in some ND/DHCP activity, but do not always
  result in layer 3 change.

I am expecting a revised draft and information about additional
reviews before proceeding.

Jari

_______________________________________________
MEXT mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/mext

---

From: Sri Gundavelli <[email-masked]>
Date: Tue, 10 Jun 2008 19:40:10 -0700 (PDT)

Hi Jari,

Thanks for the review. We will address the issues and post the
revised document.

Regards
Sri