I have been selected as the General Area Review Team (Gen-ART)
reviewer for this draft (for background on Gen-ART, please see
_http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html_).
Please resolve these comments along with any other Last Call comments
you may receive.
Document: draft-ietf-monami6-multiplecoa-10.txt
Reviewer: Elwyn Davies
Review Date: 24 November 2008
IETF LC End Date: 17 November 2008
IESG Telechat date: (if known) -
Summary:
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
there are
lots of acronyms needing expansion and minor english improvements
that
woild be tedious to transcribe.
Apologies for the late review.
Comments:
Minor Issues:
Backwards compatibility: It would be helpful to explain in the
introduction why this proposal is backwatds compatible with the RFC
3775
scheme. The explanations are there but are buried in the error
cases of
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
ID
(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
confusing
because the protocol is specified so that negative values cannot be
carried.
s4.2 (two places), s6.2 (2nd bullet), s6.2 (6th bullet, 1st sub-
bullet):
The length of the Binding Address mobility option for the IPv4 case
is
specified inconsistently. Some places have been corrected from 12
to 8
but several others remain.
s4.2: The Reserved fiels is normally specified as 'SHOULD be
ignored by
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
can
fail in part would be useful
s4.3 (MCOA MALFORNED): Some indoication of the circumstances under
which
this can occur would be useful.
s4.3 (MCOA BULK REGISTRATION PROHIBITED) and s5.3: I think there
is a
'crner case' in which a bulk registration is sent to a leagcay RFC
3775
node: the node would not be capable of this response. This corner
case
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
os
not (IP) connected to its home link!
s5.6.3 (2nd bullet) and s6.1 (para 2): Using 'ex.' is not good: It
is
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
be
able to send to the mobile node if the LLA option was omitted. I
think
this is a 'MUST' or maybe a 'needs to'.
s5.6.4 (2nd top level bullet): 'the home agent SHOULD use the link-
layer
address carried by the Link Layer Address option': Again I am not
sure
what alternative there is? Replace with either 'MUST' or 'needs to'.
s5.7 (2nd bullet): s/SHOULD/needs to/: This is not something sthat
is
an option in the protocol. Also I think it should state that the
mobile
node needs to assume that none of the attempted registrations were
successful.
s5.7 (3rd bullet): Explain what could cause the packet to be
malformed.
s5.7 (4th bullet): Replace 1st instance of SHOULD with 'needs to'.
Explain that the 2nd case can occur during 'bootsatrpa' (pointer to
s5.9).
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
some fail.
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
MUST
reject the Binding Identifier mobility option and returns the status
value set to [MCOA MALFORMED].' This is poorly phrased. If the
length
is set to 8 or 20, then there is space in the option for an address
of
some sort. It sort of implies that the bit pattern can be tested
to see
if it is a valid address - how is this done? It strikes me tht it
would
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
omitted/
Editorial:
I have sent a Word document with many nits marked up to the authors.