Subject: [ppsp] Re: Re: ppsp revised charter proposal

From: Ning Zong <[email-masked]>
Date: Tue, 19 Jan 2010 22:10:22 +0100

Thanks David for the suggestions. +1

BR,
Ning Zong

>+1
>
>-Victor
>
>On 1/18/10, Schmidt, Christian 1. (NSN - DE/Munich)
><[email-masked]> wrote:
>> Hi David,
>>
>> Thank you for the explanation, now it is clear to me and I would vote to
>> Use your text proposal for the charter.
>>
>> Regards
>> Christian
>>
>>
>> -----Original Message-----
>> From: [email-masked] [mailto:[email-masked]] On Behalf Of ext
>> David A. Bryan
>> Sent: Monday, January 18, 2010 3:27 PM
>> To: Schmidt, Christian 1. (NSN - DE/Munich)
>> Cc: ext zhangyunfei; [email-masked]
>> Subject: Re: [ppsp] ppsp revised charter proposal
>>
>> Hi Christian,
>>
>> I don't think the goal is that PPSP should not be able to request
>> changes at all -- in fact, I hope some interesting uses, which could
>> mean changes/extensions do come out of PPSP. In the case of the P2PSIP
>> charter, the language was to make it clear at charter time that P2PSIP
>> wasn't going to be directly changing SIP itself, but would go through
>> other groups. In PPSP, I think it should be to make it clear that PPSP
>> work won't be able to directly change P2PSIP/ALTO etc. specifications,
>> but would push any suggested changes needed to the respective group.
>> Perhaps it is redundant (IETF rules tend to imply a group can't
>> usually modify another group's documents), but as chair, it has proved
>> to be very useful text from a scoping perspective in P2PSIP.
>>
>> I tried to capture that in my rewrite, but if I didn't quite get it
>> right, we should certainly try changing the wording a bit more.
>>
>> David
>>
>> On Mon, Jan 18, 2010 at 9:10 AM, Schmidt, Christian 1. (NSN -
>> DE/Munich) <[email-masked]> wrote:
>>> Hi David,
>>>
>>> Your modification looks better then the orginal text.
>>> Question:
>>> Is the goal of the sentence, that e.g. requirements from PPSP should not
>>> Be able to request changes in reload-base specification?
>>> These requirements would have to be documented in a separate document?
>>> Or what should this sentence avoid?
>>>
>>> Regards
>>> Christian
>>>
>>>
>>>
>>>
>>> -----Original Message-----
>>> From: [email-masked] [mailto:[email-masked]] On Behalf Of ext
>>> David A. Bryan
>>> Sent: Wednesday, January 13, 2010 1:52 PM
>>> To: Schmidt, Christian 1. (NSN - DE/Munich)
>>> Cc: ext zhangyunfei; [email-masked]
>>> Subject: Re: [ppsp] ppsp revised charter proposal
>>>
>>> So looking at the change suggested below, essentially you are looking
>>> to remove the sentence:
>>>
>>> "The PPSP WG assumes that it cannot modify baseline P2PSIP, ALTO,
>>> LEDBAT and MMUSIC behaviors."
>>>
>>> Overall, this section of the charter is very much like (even borrowed
>>> from) the P2PSIP charter, where the similar line basically says the
>>> P2PSIP group, in itself, is not authorized to modify SIP. I think
>>> there is a similar intended here, so I wouldn't support removing the
>>> sentence entirely as you suggest, but I think different wording is
>>> might be needed (i.e., using the work "assume" almost implies that the
>>> protocols won't need to be changed, when he right wording should be
>>> more about PPSP not being the place to modify them if they need it.
>>>
>>> How about:
>>>
>>> "The work planned for the PPSP WG is distinct from, but requires close
>>> participation with, work in other IETF WGs, particularly P2PSIP,
>>> ALTO,LEDBAT and MMUSIC. While the PPSP WG cannot modify baseline
>>> P2PSIP, ALTO, LEDBAT or MMUSIC behaviors, if PPSP determines that
>>> extensions or modifications are required, PPSP may seek to define such
>>> extensions and present them to the respective working groups."
>>>
>>> Thoughts?
>>>
>>> David
>>>
>>> On Wed, Jan 13, 2010 at 4:47 AM, Schmidt, Christian 1. (NSN -
>>> DE/Munich) <[email-masked]> wrote:
>>>> Hi,
>>>>
>>>> (this time the finished mail)
>>>>
>>>> in general I think, the charter is in a good shape.
>>>> Perhaps in some points clarifications are possible.
>>>>
>>>> The following topics are excluded from this WG's scope:
>>>> 1. Transport mechanisms for data transmission among PPSP peers, e.g.
>>>> using
>>>> TCP or UDP, unicast or multicast, etc. However the  design  of  PPSP
>>>> will
>>>> consider how it can be combined with the transport mechanisms, including
>>>> NAT
>>>> traversal problem. The design of PPSP will also consider the scenario of
>>>> transmission of multiple streams  (layered  media).  This includes
>>>> considering various media descriptions (e.g. data chunk description in
>>>> peer
>>>> protocol) after investigating different media coding mechanisms (e.g.
>>>> SVC,
>>>> MDC) to incorporate their features in the protocol.
>>>>
>>>> This somehow mixes different issues:
>>>> - Transmission protocol selecion (not included)
>>>> - NAT traversal (included?)
>>>> - Usage of more then one stream for one channel (included?)
>>>> - Media descriptions (included?)
>>>>
>>>> Most of the items  are not exluded from the WG´s scope and should not be
>>>> mentioned under this headline.
>>>> My proposal would be:
>>>> - to shorten point one of excluded topic to:
>>>> 1. Transport mechanisms for data transmission among PPSP peers, e.g.
>>>> using
>>>> TCP or UDP, unicast or multicast, etc.
>>>> - to add a short passage before the WGs primary tasks:
>>>> NAT traversal, the usage of multiple streams (layered media) are in scope
>>>> of
>>>> the WG.
>>>>
>>>> The work planned for the PPSP WG is distinct from, but requires close
>>>> participation with, work in other IETF WGs, particularly P2PSIP,
>>>> ALTO,LEDBAT
>>>> and MMUSIC. The PPSP WG assumes that it cannot modify baseline P2PSIP,
>>>> ALTO,
>>>> LEDBAT and MMUSIC behaviors. If PPSP determines that extensions to
>>>> P2PSIP,
>>>> ALTO,LEDBAT and MMUSIC are needed, PPSP will seek to define such
>>>> extensions
>>>> and present to the respective working groups.
>>>>
>>>> What is the reason for this assumption? And how can we know before the
>>>> related needed extensions are known?
>>>> My proposal:
>>>> The work planned for the PPSP WG is distinct from, but requires close
>>>> participation with, work in other IETF WGs, particularly P2PSIP,
>>>> ALTO,LEDBAT
>>>> and MMUSIC. If PPSP determines that extensions to P2PSIP, ALTO,LEDBAT and
>>>> MMUSIC are needed, PPSP will seek to define such extensions and present
>>>> to
>>>> the respective working groups for evalution.
>>>>
>>>> Best Regards
>>>> Christian Schmidt
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> ppsp mailing list
>>>> [email-masked]
>>>> https://www.ietf.org/mailman/listinfo/ppsp
>>>>
>>>>
>>>
>> _______________________________________________
>> ppsp mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/ppsp
>>
>
>
>-- 
>Victor Pascual Ávila
>_______________________________________________
>ppsp mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/ppsp

= = = = = = = = = = = = = = = = = = = =
			
Ning Zong
[email-masked]
2010-01-18