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 wait for direction from your document shepherd
or AD before posting a new version of the draft.

Document: draft-ietf-mipshop-rfc5268bis-01.txt
Reviewer: Brian Carpenter
Review Date: 2009-05-05
IESG Telechat date: 2009-05-07


Summary:  Almost ready (two issues)
--------

Comments: 
--------- 

Thanks to whoever provided the diffs from RFC5268.

Author has agreed to changes for the major issues below.
The pre-5378 question is still open.

Major issues: 
-------------

I didn't notice a statement about what an implementation confirming
to this specification is supposed to do if it receives one of
the deprecated ICMPv6 messages defined in RFC5268. I would suggest
a clear definition of what 'deprecated' actually means. Something like

   Implementations of this specification MUST NOT send the ICMPv6
   messages of subtypes HI and HAck as defined in [RFC5268].
   If they receive such messages they MUST/MAY/SHOULD ????

(I don't have an opinion about this; two options would be
that they SHOULD interpret them as defined in 5268, 
or that they MUST discard them silently. I don't know all 
the implications of these choices.)


>  11.  IANA Considerations
...
>                                           The Subtype values 4 and 5	
>     are deprecated and are marked as unassigned for future allocations.

Is this safe? It would seem prudent to mark them as reserved, to avoid
future compatibility problems. Maybe this is intended, in which case
"unassigned" is the wrong word, and "unavailable" would be better.


Editorial issues:
-----------------

Given the long history of this material, does it need the pre-RFC5378
legal disclaimer?