Hi Brian, thanks for the review. Please see inline: 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]. Rajeev:> Okay, I can capture this. 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.) Rajeev:> I am thinking MAY. > 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. Unavailable is okay. Editorial issues: ----------------- Given the long history of this material, does it need the pre-RFC5378 legal disclaimer? Rajeev:> I don't know. Chairs, Jari? Thanks again, -Rajeev ________________________________ From: Brian E Carpenter [mailto:[email protected]] Sent: Mon 4/20/2009 4:07 PM To: [email protected]; General Area Review Team Cc: [email protected]; Jari Arkko Subject: Gen-ART LC review of draft-ietf-mipshop-rfc5268bis-01.txt _______________________________________________ Gen-art mailing list [email protected] https://www.ietf.org/mailman/listinfo/gen-art
