Review of draft-ietf-dmm-lma-controlled-mag-params-02

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Reviewer: Ralph Droms
Review result: Ready with Issues

Major issues:  None

Minor issues:

The mechanism described in this document is fairly simple.  I
recommend that the specific semantics of the use of the parameter
options should be explained with greater clarity to ensure correct and
interoperable implementations.  For example, I found the description
of LMA behavior in section 5.1 to be quite convoluted and confusing. 
Putting the "if...then...else" construct in two bullets seemed obtuse.
 In the first bullet, the LMA "SHOULD include" the sub-option.  Are
there circumstances under which the LMA would not include the
sub-option and, if so, what are those circumstances?  Can the LMA
decide, perhaps for efficiency, to return the sub-option in only, say,
one of ten responses to the MAG?

Is there a specific reason for encoding the LAM Controlled MAG Session
Parameters as sub-options under the LAM-Controlled-MAG-Parameters
option?  Will additional sub-options be defined in the future?

Editorial issues.

For clarity, the document should use acronyms and names for system
components in a consistent way: use acronyms throughout and expand the
acronym on first use.  For example, LMA and "local mobility anchor"
are used interchangeably throughout the document, which this reviewer
found to be distracting.

What is the expansion for "PBU"?

The use of the "Configuration Variables" defined in section 4 is
repeated in section 5.1.  To avoid internal inconsistency, I recommend
that the use of the variable be described only once, with internal
pointers to that text from other places in the document.

In section 6, it would help the reader to include the name of the
registry to be modified in the first bullet.  





[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]