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

["Spencer Dawkins" <spencer@mcsr-labs.org>]

Hi, Pekka,

Just to say this explicitly, deferring text to a pre-00 ID in 2a
defers the move to DS more effectively than referring to an existing
PS RFC in 1b :-)

Spencer

From: "Pekka Savola" <pekkas@netcore.fi>
To: <v6ops@ops.ietf.org>
Sent: Friday, May 14, 2004 5:01 AM
Subject: IESG evaluation of draft-ietf-v6ops-mech-v2-02.txt


> 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)
>
>
>
>