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-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/
_______________________________________________
Gen-art mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/gen-art
