IESG evaluation of draft-ietf-v6ops-mech-v2-02.txt

[Pekka Savola <pekkas@netcore.fi>]

Hi,

(co-chair hat on)

IESG has evaluated draft-ietf-v6ops-mech-v2-02.txt and the comments
are available at the I-D tracker, a direct link:  
https://datatracker.ietf.org/public/pidtracker.cgi?command=print_ballot&ballot_id=1250&filename=draft-ietf-v6ops-mech-v2

I'm collecting the most important ones here for feedback and opinions.  
I've followed up with most ADs for clarification, and I'm excluding
the trivial issues, misunderstandings, etc.

Issues 1) and 2) are the most important ones, and I'd appreciate
comments from the WG on those at least.

1) section 2.2 on DNS result ordering/filtering seems to be considered
inappropriately short, and it would be better to just refer to the
default address selection RFC3484. (Margaret Wasserman). Filtering is
inappropriate (Ted Hardie and Scott Hollenbeck).

==> possibilities include at least:
 a) keeping the current tense of specifying a "simple" address 
    selection, and referring to RFC3484 for more details, but reword 
    the text appropriately.  Remove filtering but keep ordering. It 
    might require some convincing to make the IESG accept this 
    approach.  (In other words, a simple dual-stack implementation would
    not necessarily have to implement RFC3484 to be 
    compliant/interoperable with this spec.)
 b) remove most of the text, referring to RFC3484.  Note that RFC3484 
    is PS, and we could not advance to DS if we did that.  (In other 
    words, all the dual-stack implementations compliant with this spec 
    would also have to implement RFC3484.)

2) the document appears to say, "just use IPsec", without giving 
sufficient details how to do it inappropriately. (Steve Bellovin)

==> possibilities include at least:
 a) adding some detail here how to set up the SA's
 b) removing all the references to IPsec and hoping that security AD's 
    don't cry out.
 c) defer to a future document to be written about the details of 
    secure v6-in-v4 tunneling; this has already started a month ago, 
    but hasn't produced a -00 draft yet.

3) security considerations describing isolating different tunnels and
interfaces from each other seems to forbid the implementation
technique of point-to-multipoint (and more, multipoint-to-point)
tunnels. (Alex Zinin)

==> this is intentional, as we removed automatic tunneling from the 
spec, but should probably be spelled out.  All the configured tunnels 
are expected to be point-to-point.

4) the spec might consider whether the tunnel end-point is resolvable; 
if not, take the tunnel down. (Alex Zinin)

==> I already agreed with Alex that this is a can full of worms, even 
if it's useful, and not something we should open here unless people 
insist. (The "resolvability" check is quite non-trivial when you have 
e.g., default or aggregate routes in your routing table.)

5) the doc needs to mention dual-stack security considerations. 
(Jon Peterson)

==> I already agreed with Jon that spelling these out here would be 
out of scope, and we'll just defer to another document, 
draft-savola-v6ops-security-overview-02.txt, for that (just like for 
3GPP analysis doc)