Re: Gen-art review of draft-ietf-monami6-multiplecoa-10.txt

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

 



Elwyn,

Thank you for the in-depth review!

Authors, when will you be addressing these issues?

Jari

Elwyn Davies wrote:
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.








_______________________________________________

Ietf@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf

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