Re: [Tsvwg] draft-ietf-tsvwg-admitted-realtime-dscp-05

[ken carlberg <[e-mail]>]

ok, but could you make a stronger case as for why?  the cited text  
presents context and recommendations with what we have on hand now,  
but doesn't make a hard requirement of MUST.  if someone else comes  
along later and defines a better widget, or simply another way of  
accomplishing the fundamental objectives of the draft with a  
different signaling protocol....great, and please let's encourage  
them to tell "us" how.

cheers,

-ken


On Jan 15, 2009, at 10:04 AM, Tschofenig, Hannes (NSN - FI/Espoo) wrote:

> Hi Ken,
>
> I would like the document not to talk about this at all.
> I don't know why it has to.
>
> Ciao
> Hannes
>
>> -----Original Message-----
>> From: [e-mail] [mailto:[e-mail]]
>> On Behalf Of ext ken carlberg
>> Sent: 15 January, 2009 15:00
>> To: Hannes Tschofenig
>> Cc: [e-mail]
>> Subject: Re: [Tsvwg] draft-ietf-tsvwg-admitted-realtime-dscp-05
>>
>> I'm afraid you've lost me.  The words "recommend" and "such
>> as" from the cited text below doesn't IMO come close to giving
>> an impression of "essentially requires".  The cited text makes
>> an observation about the work from NSIS, with (my) assumption
>> that the authors choose to discuss the topic within the
>> context of IETF signaling protocols.
>>
>> If you would like to advocate the integration of Rx/Gx (3GPP)
>> with the work at hand, perhaps it may be more helpful to
>> describe this suggested interaction in more detail with suggested  
>> text.
>>
>> cheers,
>>
>> -ken
>>
>>
>> On Jan 15, 2009, at 5:24 AM, Hannes Tschofenig wrote:
>>
>>> By coincident I ran into the following draft:
>>> http://tools.ietf.org/html/draft-ietf-tsvwg-admitted-realtime- 
>>> dscp-05
>>>
>>> Section 2.3 says:
>>>
>>> "
>>>    On the point of what protocols and procedures are required for
>>>    authentication, authorization, and capacity admission, we
>> note that
>>>    clear standards do not at this time exist for bandwidth brokers,
>>> NSIS
>>>    has not at this time been finalized and in any event is  
>>> limited to
>>>    unicast sessions, and that RSVP has been standardized and has the
>>>    relevant services.  We therefore recommend the use of RSVP at the
>>>    UNI.  Procedures at the NNI are business matters to be discussed
>>>    between the relevant networks, and are recommended but not
>>> required.
>>> "
>>>
>>> and the IANA consideration section says:
>>>
>>> "
>>>    This traffic class requires the use of capacity admission such as
>>>    RSVP services together with AAA services at the User/Network
>>>    Interface (UNI); the use of such services at the NNI is at the
>>> option
>>>    of the interconnected networks.
>>> "
>>>
>>> The text (to me) sounds like that this DSCP essentially
>> requires RSVP
>>> to be implemented in order to get this to work. This is IMHO not
>>> correct.
>>>
>>> To give you one other example of a standardized mechanism that would
>>> do the
>>> job: Rx/Gx (3GPP)
>>>
>>> Ciao
>>> Hannes
>>>
>>
>>