[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: API Discussion RE: v6ops Agenda for Atlanta
- To: "Margaret Wasserman" <mrw@windriver.com>, <v6ops@ops.ietf.org>
- Subject: RE: API Discussion RE: v6ops Agenda for Atlanta
- From: "Bound, Jim" <Jim.Bound@hp.com>
- Date: Fri, 15 Nov 2002 12:51:20 -0500
- Delivery-date: Fri, 15 Nov 2002 09:53:20 -0800
- Envelope-to: v6ops-data@psg.com
- Sender: owner-v6ops@ops.ietf.org
- Thread-index: AcKMxMmvLAYKRhbgSAqkTEXGNuJcmwABy3YQ
- Thread-topic: API Discussion RE: v6ops Agenda for Atlanta
Hi Margaret,
> Hi Jim,
>
> It is true that we did discuss the IPv4 mapped address issues in
> Sunnyvale. At that time,
> Itojun presented one draft that concerned two different parts of the
> issue: what should and
> shouldn't be sent on the wire, and what should and shouldn't
> be passed by
> the API,
> particularly in a dual stack.
Yes I was there.
>
> There was some agreement in the meeting that there are issues
> with using
> IPv4 mapped
> addresses on the wire that need to be documented, although it
> was not clear
> what action we
> should recommend to correct these issues -- updating the
> IPv6 addressing
> architecture,
> modifying SIIT, etc.
I agree and was there.
>
> The API portion was much more controversial, and there was a general
> consensus in the room
> not to impose any API changes on existing implementations.
> Of course, the
> whole WG was not
> necessarily represented at the meeting.
What you say is true and that was the feeling. My issue is that this
was discussed on ipng and the apifolks design team. So what we heard at
Sunnyvale Interim meeting is consensus already and Itojun and Craig know
that. So I don't see why we are revisting it again. But it feels like
v6ops is being duped to bring it up yet again. The problem is that the
current API defaults are deployed in production and supported in
practice and spirit by all but two implementations is my knowledge. The
API is now not 2553 but an IEEE spec/std.
So I sense politics here but if you want to have this come up again that
is your choice as chair. But we are not going to break customers at
this point using IPv6 is my strong guess.
>
> Based on the input they received in Sunnyvale, Craig and
> Itojun have split
> the document into
> two parts -- the on-wire part and the API part, and they have
> updated both
> parts. This will
> allow us to consider the two parts separately.
That is good.
>
> There was enough interest and discussion in Sunnyvale, at
> least regarding
> the on-wire issues
> that it seemed worthwhile to discuss this again in Atlanta to
> see if this
> is something that the
> v6ops WG should document.
If this is the discussion I fully agree.
Thanks for listening to my point and responding,
/jim