Review comments on draft-ietf-shim6-proto-03.txt

[Geoff Huston <gih@apnic.net>]

So with my WG chair hat off, I've reviewed the protocol draft 
(draft-ietf-shim6-proto-03.txt) and I have prepared a set of comments. They 
are devided into general approach comments about document and editorial nits.

In this posting I'll make a number of general comments on the draft. I'll 
send the editorial nits directly to the document authors if thats ok.

1 - Protocol Overview vs Protocol Specification

I was confused whether section 4 is a part of the actual protocol 
specification or whether it was a more general set of overview comments 
about the characteristics of the particular approach described here. What 
threw me was a number of MUSTs in section 2, which lead me th think this 
was part of the specfication, while most of the section was of a more 
discussive style.

It appears that sections 7 through 14 are the actual protocol 
specification, while section 4 is in deed a discussive section rather than 
a specification.

One way to clarify this would be to remove the RFC2460 MUSTS SHOULDs, etc 
from section 4, and use an introductory sentence to note that this is an 
informal overview of the protocol, and note that the protocol specification 
is contained in the following sections.

It may also be useful to encapsulate the current sections 7 though 14 into 
a single section 7 and call it "Protocol Specification", although this is 
more of a personal style preference.

2 - section 1.4 - Multicast

Could this be better relocated into section 16 (Implicatons Elsewhere)? 
with a single line statement in 1.2 ( Non-Goals) that IP multicast is not 
supported in Shim6?

3 - section 1.5 renumbering implications

Could this be better relocated into section 16 (Implications Elsewhere?). 
It semes a better fit there than in section 1

4 - section 1.7 Traffic Engineering

It may also be appropriate to include some considerations of traffic 
engineering in section 19, and note in section 19 some of the issues 
related to externally generated triggers for locator change and 
externally-supplied locator preferences that would allow some form of TE 
responses at a host.

5 - Section 3 - Assumptions

The assumptions note the consideration of Ingress Filtering and 
source-based path selection considerations, and appears to state the same 
assumption twice. Perhaps an appendix should include further text in the 
source address / site exit selection / path selection considerations that 
are implictly assumed in this specification. It may also be useful to 
reference some of the previous multi6 work on the issues of source address 
section / site exit router selection.

6 - Section3 - Assumptions

I suspect that we assume that there are no IPv6 NATS on the path - perhaps 
this should be explicitly stated

7 - Section 4.6 - comment on Mobile IPv6

It may make sense to explicitly call out the "for further study" comment in 
this section in section 19.

8 - Section 8 - handling ICMP error messages

It may be me, but I found this section somewaht opaque. Either a diagram or 
some further text may help in terms of understanding what transforms are to 
be applied to the ourter ICMP packet header locators and what transforms 
are to be appied to the inner packet segment that is in the payload of the 
ICMP packet.

9 - section 11 - Sending ULP payloads

It is implied by the text here that if SHIM6 context reestablished use of 
the initial locator pair as the current locators (ie. start with ULID = 
locators, switch to new locators and then switch back to original ULID = 
locator) then no packet transforms as specified in section 11.1 are 
required. Should this be called out in the text?

As a meta consideration here, is there any logical reason to prefer the 
initial ULIDs as locators?

10 - section 19 Possible protocol extensions

possible additional parts here could include:

- allowing the API to trigger a locator change as well as locator preference?

- allowing external triggers for locator preference and locator switch (TE 
related)