Document: draft-stjohns-sipso-06.txt
Reviewer: Elwyn Davies
Review Date: 28 January 2009
IESG Telechat date: 29 Jan 2009

Summary:
Almost ready.  There are a couple of issues that need discussion - the authors have requested IESG input on the IANA considerations.

Most of the issues in my review of -05 have been addressed.

Major issues:
s9.2: The authors have requested IESG assistance with the IANA considerations section. The section does not currently have a well defined allocation policy (it is sort of FCFS with expert review on the side).

Minor issues:

s5, para 4: This paragraph, added after the previous review, provides good general guidance on what happens when IPv4 is tunnelled over IPv6 or vice versa. I am not an expert in this area, but I wondered if more specific guidance on mapping between the IPv4 security option and the
IPv6 security option was desirable?

s5.1.1, IPv6 Option Type: I commented in the review of -05 that specifying 'ignore if unrecognized' rather than 'drop if unrecognized' 
seemed to be contrary to the idea that this option should only be used in networks that understand it.  This section now contains some justification for the choice, citing the possibility that some routers in an MLS system might not understand the option and must still pass it on.  Given the extreme precautions implied by the remainder of this specification, this seems perverse.

s6.3.3, item 4:
            In all cases, if an ICMP Error Message is sent,
            then it MUST be sent with the same Sensitivity
            Label as the rejected datagram.
I think it is worth pointing out here that the Sensitivity Label implied is the one from the *original* datagram.  This section is dealing with the 'output side' and the rejection may be of a *translated* datagram that has a different label from the incoming datagram (which might actually not have had a label at all). Maybe  s/rejected datagram./incoming datagram that resulted in the datagram being rejected on the output interface.  If the incoming datagram was unlabelled the ICMP message will also be unlabelled./.

s9.2- statements about range 0:0:0:1 to 0:255:255:255:
   'DOI values beginning with decimcal 0:0:0 are reserved for
   private use amongst consenting parties; values in this range
   will not be allocated by IANA to any particular user or user
   community.  For reasons of interoperability, these DOI values
   MUST NOT ever appear on the global public Internet.'

- The text below the table is inconsistent with the table value - it is not just values beginning 0:0:0.
- The statements about appearance on the global Internet are (1) unenforceable by the protocol and so should not contain 'MUST NOT' 
terminology and (2) are intended to specify that they shouldn't escape from the private network on which they are used. Removing these statements (two places) would be good idea and would still provide the necessary information.
- (editorial) s/decimcal/decimal/

Editorial:
s8, next to last para: 'Alternatively, a CALIPSO
   labelled IPv6 packet might over some external link'
s/might over/might travel over/