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

["Tschofenig, Hannes (NSN - FI/Espoo)" <[e-mail]>]

Hi Ken, 

Don't give up so quickly. I know, you are not the author of the document
but let us look at the text in detail and my proposal for change: 


2.3.  Recommendations on implementation of an Admitted Telephony Service
      Class

   It is the belief of the authors that either PHB implementation
   described in Section 2.1, if coupled with adequate AAA and capacity
   admission procedures as described in Section 2.2, are sufficient to
   provide the services required for an Admitted Telephony service
   class.


CHANGE PROPOSAL:
"
   It is the belief of the working group that either PHB implementation
   described in Section 2.1, if coupled with adequate AAA and capacity
   admission procedures as described in Section 2.2, are sufficient to
   provide the services required for an Admitted Telephony service
   class.
"

REASON: I hope the working group believes it as well and not only the
authors. 

   If preemption is required, as described in section 2.3.5.2 of
   [RFC4542], this provides the tools for carrying out the preemption.
   If preemption is not in view, or if used in addition to preemptive
   services, the application of different thresholds depending on call
   precedence has the effect of improving the probability of call
   completion by admitting preferred calls at a time that other calls
   are being refused.  Routine and priority traffic can be admitted
   using the same DSCP value, as the choice of which calls are admitted
   is handled in the admission procedure executed in the control plane,
   not the policing of the data plane.

   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.

CHANGE PROPOSAL:

"
As previously noted, the PHB implementation requires the QoS resource
request triggered from the end device (UNI interface) and the subscriber
to be authenticated and authorized. Different mechanisms are available
for conveying the QoS information and also for performing the
authentication and authorization. This document does not mandate a
specific protocol to be used. 
"

REASON: The discussion regarding NSIS vs. RSVP is irrelevant for this
document. The recommendation for RSVP is not necessary in order to
accomplish the overall goal of this document. 

5.  Security Considerations

   A major requirement of this service is effective use of a signaling
   protocol such as RSVP, with the capabilities to identify its user
   either as an individual or as a member of some corporate entity, and
   assert a policy such as "routine" or "priority".

   This capability, one has to believe, will be abused by script kiddies
   and others if the proof of identity is not adequately strong or if
   policies are written or implemented improperly by the carriers.  This
   goes without saying, but this section is here for it to be said...

A question: Is there really a (major) requirement to identity the user
as individual or as a member of some corporate entity? I would have said
that there are authentication and authorization requirement but not
necessarily regarding the membership. 

4.  IANA Considerations

   This note requests that IANA assign a DSCP value to a second EF
   traffic class consistent with [RFC3246] and [RFC3247] in the
   "Differentiated Services Field Codepoints" registry.  It implements
   the Telephony Service Class described in [RFC4594] at lower speeds
   and is included in the Real Time Treatment Aggregate [RFC5127] at
   higher speeds.  The recommended value for the code point is 101100,
   paralleling the EF code point, which is 101110.  The code point
   should be referred to as VOICE-ADMIT.

   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.

SUGGESTION: Delete last paragraph as it does not add anything beyond
what was said in the document.

Ciao
Hannes

>-----Original Message-----
>From: ext ken carlberg [mailto:[e-mail]] 
>Sent: 15 January, 2009 15:34
>To: Tschofenig, Hannes (NSN - FI/Espoo)
>Cc: Hannes Tschofenig; [e-mail]
>Subject: Re: [Tsvwg] draft-ietf-tsvwg-admitted-realtime-dscp-05
>
>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
>>>>>>
>>>>>
>>>>>
>>>
>>>
>
>