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

[ken carlberg <[e-mail]>]

no, and this discussion is becoming circular.  I go back to the  
preciseness of the language in the text of the draft that discusses  
RSVP as a recommendation, not a requirement in the form of a must.

to follow your line of reasoning, we would need to go back to all  
protocols that interact with SIP and say "please consider other  
protocols like H.323, and perform the interaction in the following  
way (blah, blah, blah)", since there are others means to signal the  
establishment of sessions.

the two of us seem to agree to disagree.

kindest regards,

-ken


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

> Creating the perception that only RSVP can be used to provide the
> required functionality does not reflect reality.
> If one wants to be fair then this has to be stated. When protocols are
> discussed then it would be fair to say that there isn't only RSVP and
> NSIS.
>
> Does this make sense to you?
>
> Ciao
> Hannes
>
>> -----Original Message-----
>> From: ext ken carlberg [mailto:[e-mail]]
>> Sent: 15 January, 2009 15:13
>> To: Tschofenig, Hannes (NSN - FI/Espoo)
>> Cc: Hannes Tschofenig; [e-mail]
>> Subject: Re: [Tsvwg] draft-ietf-tsvwg-admitted-realtime-dscp-05
>>
>> 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
>>>>>
>>>>
>>>>
>>
>>