[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: initial issues



Masataka,

> > Once we all get to know each other and get some productive 
> stuff done then
> > have it by all means.  But lets just get a charter, strategy, begin
> > requirements definition and not try to change what one may 
> or may not like
> > in IPv6 right now.  That is really why IPng exists.  This 
> list is not a back
> > door to change what is in IPng's charter.
> 
> You misunderstand the point.
> 
> Multi6 will be a place to discuss, for multihoming, IPv6
> routing/addressing, which is currently withing a scope of IPng WG.

I would like to hear from the Thomas on this one? 

multihoming I agree with you.  I think Itojun is the only technical proposal
on the list thus far to try to approach what the requirements and discussion
can revolve around.

IPv6 Routing??  That is in the Routing Area of the IETF and the charter of
this group is 
not I hope to try to build routing protocols.  But look at them most likely
to see if adding any attributes to them may benefit multihoming and report
that back to the routing area.

IPv6 addressing is not to be done here but in IPng.  Clearly as routing the
WG will have to look at addressing as it relates to operators, nodes, and
providers.  But any changes to the IPv6 Addressing Architecture is in the
charter of the IPng WG in the Internet Area of the IETF.

So I think you or I may need clarification from Thomas and others but I
think your extending what we will actually do in this WG.
 
> According to your logic, such WG can not exist.

On the contrary, if we focus on Multihoming we have plenty of work to do.
That does not mean input is not generated from the WG that is for other
areas and WGs within our community.  Like any engineering group.

> 
> Worse, the expected changes are on transport/application protocols.

I don't see that at all and again if there is a need for changes to the
above that is
not and should not be the charter of this group.

> 
> IPng WG is chartered explicitely not to discuss such issues.
> 
> 	TCP/UDP: The IPng Working Group will specify the
> 	procedures for hosts to compute and verify TCP/UDP
> 	pseudo-headers. Any other changes to TCP beyond
> 	making TCP work with IPng are out of scope of the working
> 	group and should be dealt with by a TCPng Working Group. 
> 
> So, it is a scope violation for members of IPng WG claim "TCP
> protocol changes are not acceptable".

I or no one has done that.  If multihoming for some strange reason sees that
changing TCP, UDP, or SCTP for some reason then that would go to the
transport area of the IETF.

/jim