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

[Fred Templin <ftemplin@iprg.nokia.com>]

Going back to a note from several weeks ago, I was wondering if there
was any new status to report on the open issues for mech-v2-02. e.g.,
are the authors maintaing an issue tracker page somewhere? Speaking
of the authors, I was wondering if the second author (Bob Gilligan)
has been active in the MECH(bis) effort, since it has been some time
since I have seen any messages from him on the mailing lists.

I am well aware that Bob has made significant past contributions
that should be properly honored, but I was wondering what the
policy is here? (I.e., will the MECH(bis) document be allowed
to advance w/o Bob's active involvement?)

Thanks - Fred
ftemplin@iprg.nokia.com

Pekka Savola wrote:

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