I have been selected as the General Area Review Team (Gen-ART)
reviewer for this draft (for background on Gen-ART, please see
Please resolve these comments along with any other Last Call comments
you may receive.
Reviewer: Elwyn Davies
Review Date: 24 November 2008
IETF LC End Date: 17 November 2008
IESG Telechat date: (if known) -
This document is almost ready for the IESG. It has a number of minor
issues plus a fair number of editorial nits.
I am sending the editirial issues to the authors separately as
lots of acronyms needing expansion and minor english improvements
woild be tedious to transcribe.
Apologies for the late review.
Backwards compatibility: It would be helpful to explain in the
introduction why this proposal is backwatds compatible with the RFC
scheme. The explanations are there but are buried in the error
s5.7 and is easily mossed (as I did on early reading).
Extension to IPv4 correspondents etc: Something about this in the
ontroduction would also help.
s2 and several other places (s4.2, s5.1): Use of zero as a binding
(BID) is forbidden. It is unclear why this value is not allowed - it
does not AFAICS specify reversion to RFC 3775 behaviour or anything
similar: Forbidding it seems gratuitous.
s2: Specifying that the BID must not be negative is sloghtly
because the protocol is specified so that negative values cannot be
s4.2 (two places), s6.2 (2nd bullet), s6.2 (6th bullet, 1st sub-
The length of the Binding Address mobility option for the IPv4 case
specified inconsistently. Some places have been corrected from 12
but several others remain.
s4.2: The Reserved fiels is normally specified as 'SHOULD be
the receiver'. Makes it easier to cope with later changes.
s4.3 (MCOA NOTCOMPLETE) and elsewhere (s6.2): I am dubious about the
non-transactional nature of bulk registrations: some additional
discussion of why it should be reasonable that a bulk registration
fail in part would be useful
s4.3 (MCOA MALFORNED): Some indoication of the circumstances under
this can occur would be useful.
s4.3 (MCOA BULK REGISTRATION PROHIBITED) and s5.3: I think there
'crner case' in which a bulk registration is sent to a leagcay RFC
node: the node would not be capable of this response. This corner
is not described in s5.3
s5.3: What error status is sent if the user has an Alernate care-of
address option with a bulk registration?
s5.5.2, last para: Arguably, if the interface is shut down the node
not (IP) connected to its home link!
s5.6.3 (2nd bullet) and s6.1 (para 2): Using 'ex.' is not good: It
not a standard abbreviation. I take it 'except' is meant.
s5.6.3 (3rd bullet): 'The mobile node SHOULD include the Link-layer
Address (LLA) Option': I do not understand how the home agent would
able to send to the mobile node if the LLA option was omitted. I
this is a 'MUST' or maybe a 'needs to'.
s5.6.4 (2nd top level bullet): 'the home agent SHOULD use the link-
address carried by the Link Layer Address option': Again I am not
what alternative there is? Replace with either 'MUST' or 'needs to'.
s5.7 (2nd bullet): s/SHOULD/needs to/: This is not something sthat
an option in the protocol. Also I think it should state that the
node needs to assume that none of the attempted registrations were
s5.7 (3rd bullet): Explain what could cause the packet to be
s5.7 (4th bullet): Replace 1st instance of SHOULD with 'needs to'.
Explain that the 2nd case can occur during 'bootsatrpa' (pointer to
s6.2 (para 2): If bulk registrations are not transactional (which I
would have preferred) need to make it clear what happens with the
vrarious multiple mobility options when some are succcessful and
s6.2 (2nd bullet): 'When the Length value is either 8 or 20, the
care-of address MUST be present in the Binding Identifier mobility
option. If the valid care-of address is not present, the receiver
reject the Binding Identifier mobility option and returns the status
value set to [MCOA MALFORMED].' This is poorly phrased. If the
is set to 8 or 20, then there is space in the option for an address
some sort. It sort of implies that the bit pattern can be tested
if it is a valid address - how is this done? It strikes me tht it
simpler just to day that the address is ignored if present when not
required (or, if being paranoid, must be the same as was previously
registered (if present) when deleting a registration).
s6.2 (1st para after lost of bullets): s/can be omitted/MAY be
I have sent a Word document with many nits marked up to the authors.