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-mipshop-rfc5268bis-01.txt
Reviewer: Brian Carpenter
Review Date: 2009-04-21
IETF LC End Date: 2009-04-27
IESG Telechat date: (if known)
Summary: Almost ready (two issues)
--------
Comments:
---------
Thanks to whoever provided the diffs from RFC5268.
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?
_______________________________________________
Gen-art mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/gen-art
