Subject: [Gen-art] Gen-art review of draft-stjohns-sipso-06.txt

From: Elwyn Davies <[email-masked]>
Date: Wed, 28 Jan 2009 09:07:22 +0000

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-masked]
https://www.ietf.org/mailman/listinfo/gen-art