To answer your question about participation, I can definitely volunteer to work
on the requirements and solution for this effort. We will try to produce a
draft explaining the problem and need for peer participation in ALTO by the
deadline for Minneapolis.
With respect to process, I think this one takes the cake among abominations.
Having been at the IETF long enough and having participated in several BoFs,
I'm quite familiar with RFC2418 and the process. Here we have an effort that
started with a closed/gated workshop outside the IETF, was brought into the
IETF as a BoF in RAI that ended in an inconclusive manner and transitioned now
into a WG proposal for APP with little to no explanation to the wider audience
on the rationale. So, it may be best if we didn't really get into the process
discussion with this effort.
I'm just hoping that at this stage, the ADs are going to hear all opinions and
also use technical judgment on the relative points that are being made.
Best regards,
Vidya
-----Original Message-----
From: Woundy, Richard
[mailto:Richard_Woundy(_at_)cable(_dot_)comcast(_dot_)com]
Sent: Thursday, October 16, 2008 12:34 PM
To: Narayanan, Vidya; Lisa Dusseault; Vijay K. Gurbani
Cc: p2pi(_at_)ietf(_dot_)org; ietf(_at_)ietf(_dot_)org
Subject: RE: [p2pi] WG Review: Application-Layer Traffic
Optimization (alto)
Vidya,
This would be a big mistake on our part. b) is not a
research problem
and it is very much related to the same problem being solved in ALTO.
Personally, I can see that there is value in "b): information
that peers decide to make available about themselves to other
peers for this purpose". Your example below was information
about whether a client is on a wireless network. In an
earlier thread, I had suggested that clients may want to
reveal their "available access bandwidth" in a similar
fashion; see
<http://www.ietf.org/mail-archive/web/p2pi/current/msg00658.ht
ml>. So even as an "ISP person", I can see where you are coming > from.
But if I am interpreting RFC 2418 correctly
<http://tools.ietf.org/html/rfc2418>, it is not sufficient to
decide if "b)" is a worthy IETF activity, but that there are
enough participants working on "b)" for an IETF effort to be
successful. Quoting from parts of RFC 2418 section 2.1:
"Is there sufficient interest within the IETF in the working
group's topic with enough people willing to expend the effort
to produce the desired result (e.g., a protocol specification)?"
"Is there enough expertise within the IETF in the working
group's topic, and are those people interested in
contributing in the working group?"
"Does a base of interested consumers (end-users) appear to
exist for the planned work? Consumer interest can be
measured by participation of end-users within the IETF
process, as well as by less direct means."
You said:
Given that Lisa is looking for solutions, I almost wish I have a
solution thought out :) But, I don't.
Are you volunteering to work on requirements and/or solutions
for "b)"?
Would others?
(I may be interested and supportive in the future, although
right now I am predictably focused on activities related to "a)".)
If there isn't a quorum to work on "b)" right now, this could
be revisited in the future with a re-charter of ALTO, when
such a quorum does exist.
If there is a quorum, it would be helpful to hear about it.
-- Rich
-----Original Message-----
From: p2pi-bounces(_at_)ietf(_dot_)org
[mailto:p2pi-bounces(_at_)ietf(_dot_)org] On
Behalf Of Narayanan, Vidya
Sent: Wednesday, October 15, 2008 7:48 PM
To: Lisa Dusseault; Vijay K. Gurbani
Cc: p2pi(_at_)ietf(_dot_)org; ietf(_at_)ietf(_dot_)org
Subject: Re: [p2pi] WG Review: Application-Layer Traffic Optimization
(alto)
Lisa,
There's plenty of work to do in a). My recommendation based on
estimation of appropriate scope as well as an estimation of the
consensus here, would be to do that first -- to have a
charter that is
scoped to (a). Then the possibilities for
(b) include working in the P2P research group, individual
submissions,
and /or a new BoF/WG. Another option would be a future
charter update
for ALTO if it's successful and there's consensus for it to be the
basis for (b).
This would be a big mistake on our part. b) is not a
research problem and it is very much related to the same
problem being solved in ALTO.
Letting each p2p application come up with its own mechanism
of doing b) only kills the interoperability and
extensibility. We keep talking about scope creep here, but,
we seem to miss something critical. By not keeping the
related problems together in producing solutions, we are only
increasing the number of different mechanisms that are going
to be needed in future to provide this one service - I cannot
understand why that is a good thing.
Without allowing for b), I think information that a) gives
you can be more or less useless in some circumstances. Let
me provide some additional context here. One of the pieces
of information that is important to allow wireless devices to
participate in p2p networks is the basic fact that a given
node is wireless. This may place some fundamentally
different criteria on path selection decisions that cannot be
deduced simply with topology information.
For any forward looking work we do at the IETF, we must stop
designing just for wired (and stationary) devices. These are
the designs that tend to look horrible when adapted to the
wireless (and mobile) world and I seriously hope that that is
not where we are headed with this work.
Best regards,
Vidya
Lisa
_______________________________________________
p2pi mailing list
p2pi(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/p2pi
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf