service id comments

8/10/2019 Service Id Comments

1/24

Comments on: draft-drage-sipping-service-identification-01

No. Location Comment

type

Commentor Comment Resolution

1 5.1.3 NIT Ian Elz

Section 5.1.3 1st paragraph: "reachs" ->"reaches"

Fixed

2 2 NIT Ian Elz Reference [6] I think yo !ean RF" 3325 in thi# reference and al#o $herethe reference i# !ade %ection 2 2nd &ara'ra&h.

The only comment from my previos list !hich does not appear in

the ne! version is the correction to the #C nm$er in ef %. This

shold $e 33&5.

Fixed

3 (.1) 5.1.2 "ontext Ian ElzIn %ection# (.1 and 5.1.2 yo !ention *+,##erted+Identity. I do not #ee thecontext of the reference to the#e header# in thi# draft or in the &o#ition# in$hich they are inclde din the draft.

Fixed already in +-1

( eneral /&eni##e#

Ian Elz

There are 3 re!ainin' o&en i##e# in the draft. I a! n#re if the#e needto 0e re#oled 0efore the draft can reach RF" #tat#.

Fixed already in +-1

5 1 /&eni##e#

Ian Elz /I1 + Introdction + hat i# a #erice

I# a definition of the ter! #erice really re4ired in thi# doc!ent. Fro!!y readin' of the doc!ent the intent i# to define header# $hich $illena0le a #erice identity to 0e &a##ed in a %I* Re4e#t and to define a

#trctre $hich $ill allo$ re'i#tration of the identitie# of the #erice#. Thedefinition of a #erice i# ot#ide thi# #co&e. hile the definition of a#erice i# intere#tin' it i# not a key a#&ect of thi# doc!ent.

Fixed already in +-1.Reference i# !ade todraft+ietf+#i&&in'+#erice+identification a# the 0a#i#for thi#.


2/24

*ro&o#ed Text

The definition of the ter! #erice i# ot#ide the #co&e of thi#

doc!ent. %e&arate actiity i# 0ein' ndertaken to re#ole thi#i##e. Thi# doc!ent li!it# it# #co&e to definin' the header#nece##ary to &a##in' of the #erice identity and the #trctre fordefinin' the #erice identitie#.

6 1 /&eni##e#

Ian Elz /I2 + Introdction + Reference to &ro&o#ed %I**IN doc!ent.

I# thi# reference re4ired. The note a0oe i# 4ite ex&licit in #tatin' thatexten#ion of %I* !ay 0e re4ired to allo$ for identification of a &articlar#erice. Thi# fact #hold 0e eno'h.

Reference contine# #ee a0oe for definition of#erice.

7 (.3 /&eni##e#

Ian Elz /I3 + %ection (.3 + %erice Identifier and ,&&lication Identifier#.

I a! n#re that $hat i# here i# actally an i##e and it cold 0e re$ritten

a# a #tate!ent rather than an i##e.

*ro&o#ed Text

The #yntax defined 0elo$ &roide# the ca&a0ility to di#tin'i#h0et$een #erice identifier# and a&&lication identifier#.

It i# crrently not clear $hether thi# ca&a0ility i# needed 0t thea0ility to #e thi# ca&a0ility add# flexi0ility to the definition. If the#ole &r&o#e i# to identify a &articlar ,*I $ithin the end ter!inal)then it !ay $ell 0e that the exten#ion# &roided 0y [11] flfil# thi#&r&o#e $ithin the 'enine #a'e of a !edia featre ta'.

No di#tinction i# no$!ade in the text 0et$een#erice# and a&&lication#.8ifferent identifier root#are &roided $ithin the9RN ho$eer.

: eneral Ian ElzThere are also a cople of references '(() !here yo have thereferences listed in the docment.

Fixed

; eneral %ecritydirectorate?

I have to say up front that I'm very unhappy with thisdocument. It doesn't say what its status is, but I seefrom the tracker that it's informational, notstandards-track. Still, it seems to provide very

category*"info" added

to top of docment.


3/24

little information, and waves its hands about too manythings.

1- 1 %ecrity

directorate?

It also has enough problems with grammar that I'm oftennot sure what it's trying to say. The very firstsentence of the introduction, for example

This document describes private extensions to theSession Initiation !rotocol "SI!# that enable a network of trusted SI!servers to assert the service and for users entitled to that service.

I can't parse that sentence, and I don't know what itmeans to say. Similarly for the beginning of section$.%

The !-!referred-Service header field is used from auser agent to a trusted proxy to carry the preferred service of theuser sending the SI! message wishes to be used for the !-&sserted-Service field value that the trusted element will insert.

It's hard to decide on the technical content of adocument when there are what seem to be key bits thataren't readable.

+ntrodction changed

to: "This docment

descri$es privatee(tensions to the

Session +nitiation

,rotocol S+, that

ena$le a net!or/ of

trsted S+, servers to

assert the service

possi$ly s$ect to theser $eing entitled to

that service. "

.& modified to: " The

,-,referred-Service

header field is sed

from a ser agent to a

trsted pro(y to carry

the preferred service of

the ser sending the

S+, re2est that the

ser !ishes to $e sedfor the ,-sserted-

Service field vale thatthe trsted element !ill

insert."11 eneral %ecrity

hat I (can( understand seems to be missing a lot. Itseems to me that this document is basically defining

T4 S467


4/24

directorate? two new SI! header fields, !-&sserted-Service and !-!referred-Service. The document is very vague --necessarily so, it says -- about the actual usage ofthese fields, and that's the second thing that makes meunhappy with publishing this. The vagueness results inmy not understanding what it is that these fields areused to assert or re)uest, why and when a SI! re)uestwould want*need to use these "and when it wouldn't#,and what, exactly, happens when they're used. I can'timagine that an implementor who didn't already knowwhat was going on would get things right based onreading this document. &nd my experience with evensimple protocol standards is that there are manyimplementors who get things wrong even when the specsare clearly written -- and SI! is not a simplestandard.

12 %ecritycon#ideration#

%ecritydirectorate?

The third thing that bothers me is that the Security+onsiderations section blows off all considerations,even though there are many references in the documentto security-related issues. Trust domains are talkedabout often, and there are ST and ST /Tre)uirements for passing around information andcredentials. one of that is brought up as a securityconsideration. 0or example, here's something, insection 1.2.3, that I think has to be discussed in thesecurity considerations section

If a & is part of the Trust 4omain from which itreceived a re)uest containing a !-&sserted-Service header field, thenit can use the value freely but it ST ensure that it does notforward the information to any element that is not part of theTrust 4omain.

#ollo!ing paragraph

added to serviceconsiderations:

"The trst domain

provides a set of

servers !here the

characteristics of the

service are agreed for

that service identifier

vale8 and that the

calling ser is entitled

to se that service.

draft-ietf-sipping-service-identification

9(ref target*"+-.draft-

ietf-sipping-service-


5/24


6/24

of authenticated users.So I do really think that these private networks shouldhave the freedom to define an its own (private( labelthat define a service, especially if you consider thatthis label is thought to be used only within theprivate networks.

7eally, I don't understand why something that should beused only within private*trusted network, like 38!!,should re)uire the usage of a I&& registered label.

< least if I'mreading thenamespaceconsiderationscorrectly.

Salvatore 6oreto

responded:I am totally infavor of a 3gpp I4proposal.in fact I am >ustasking ?eith tomodify the service-identificationdraft and letpossible the usageof /rgani=ational

namespace.

&t present in the?eith draft(creating a newservice at the top-level re)uires aI&& registration(.

=4T S4671( eneral Eric


7/24

6owever, the mechanisms described in the draft for !-!referred-Service have no utility and, in fact, mayresult in harmful behavior.

To wit, consider the following section from the draft 1.2.2. !rocedures at ser &gent +lients "&+#

The &+ &@ insert a !-!referred-Service in are)uest that creates a dialog, or a re)uest outside of a dialog. Thisinformation can assist the proxies in identifying appropriateservice capabilities to apply to the call. This information ST /Tconflict with other SI! or S4! information included in the re)uest.0urthermore, the SI! or S4! information needed to signal functionality ofthis service ST be present. Thus if a service re)uires a videocomponent, then the S4! has to include the media line associated withthat video componentB it cannot be assumed from the !-!referred-Service header field value. Similarly if the service re)uiresparticular SI! functionality for which a SI! extension and a7e)uire header field value is defined, then the re)uest has to includethat SI! signalling

as well as the !-!referred-Service header fieldvalue.

hat this says is all of the information re)uired to

identification" as

defined in draft-ietf-

sipping-service-

identification 9(ref

target*"+-.draft-ietf-sipping-service-

identification" ;>.

nd the follo!ing te(t

to the definition of ,-

sserted-Service:

" The ,-sserted-

Service header field

carries information that

is derived serviceidentification. hile a

declarative service

identification can assist

in deriving the valetransferred in this

header8 this shold $e

in the form of

streamlining the correct

derived service

identification."

&nd the followingtext to thedefinition of !-!referred-Service


8/24

route the call "i.e., determine the service# iscontained in the ICITA message. Stated differently,the !-!referred-Service header !7/CI4AS / SA0;I0/7&TI/.To date, in discussions in the SI!!I8 ork 8roup,there have been virtually no service examples for whichthe !-!referred-Service header adds any information.In fact, the examples for which the !-!referred-Serviceheader added value highlight why this header will bedetrimental to the Internet.amely, the use cases where it does add information arecases where the SI! protocol itself is deficient.

hat makes this use detrimental is the !-!referred-Service approach is, by definition, proprietary andnon-interoperable. 7ather than repairing or extendingthe base protocol, this header will encourage :)uickfixes: that do not address the underlying problem. &tthat point the !-!referred-Service takes on protocolmeaning, ACA /TSI4A & ;IITA4 4/&I. The problem isthis protocol meaning is proprietary and by definitionnon-interoperable. oreover, the draft presents nonegotiation mechanism, nor do I see how there couldpossibly be a negotiation mechanism.Standard SI! user agents and proxies will not be ableto negotiate common communication parameters if a keyprotocol element is proprietary.

oreover, use of the !-!referred-Service in this mannerwill encourage proxies and user agents to not bother toparse and interpret the existing information contained

in the SI! ICITA. &t this point, the protocol is nolonger SI!.

To reiterate, I have no problem with the publication of!-&sserted-Service, as defined in the above named

: The !-!referred-Service headerfield carriesinformation that isdeclarative serviceidentification.Such informationshould only be usedto assist inderiving a derivedserviceidentification atthe recipiententity.

"

4 =

#?T


9/24

draft, as an IAT0-reviewed publication.

6owever, I would strongly ob>ect to the publication of!-!referred-Service as an IAT0 reviewed publication.It presents a clear and present danger to the Internet,and could potentially end the possibility of havinginteroperable communications in the Internet.

Tim !ight posted:&pparently you feel strongly about this, but I don'tunderstand what you're saying. I thought I'd try andclarify what I'm missing, before posting to the listand being :repeatedly educated:.

0irst with respect to the mechanisms defined in 1.2.2which you say :have no utility and, in fact, may resultin harmful behavior.:

@ou indicate that :hat this says is all of theinformation re)uired to route the call "i.e., determinethe service# is contained in the ICITA message.Stated differently, the !-!referred-Service header!7/CI4AS / SA0; I0/7&TI/.:

Duestions

2# is :routing the call: synomymous with :determiningthe service:5+onsider an analogy with diffserv. The 4S+! does notaffect the routing of the packet but it may influencethe way the packet is handled by the routers traversed"i.e., the :service: provided at ;3, to the packet#.6ence it seems there is precedent for separatingservice and routing.oreover the interpretation of 4S+! "mapping to !6Eetc.,# is defined only within an administrative domain,


10/24

which some might call :proprietary and noninteroperable:. @et we accept it, we've deployed it,the Internet didn't break. hy was it /? in that caseto distinguish service from routing, and define servicesuch that its meaning may be different in different

administrative domains, but not /? in this case5/r is that a misunderstanding on my part, of what !-!referred-Service is meant to achieve5

%# @ou seem to be arguing that !-!referred-Service canonly be a summari=ation of information that must beelsewhere in the packet. I don't read it that way. Iread it to say that !-!referred-Service cannotcontradict information elsewhere in the packet, nor canit be used instead of information for which a standardrepresentation is defined. Eut I don't understand thisto mean that !-!referred-Service cannot provideadditional information.

&n example. Suppose Ceri=on offers an :enhanced callscreening: service to its CoI! subscribers. Supposethat the network's implementation of this serviceinvolves invocation of a collection of functions spreadover a collection of application servers. & straightforward way to implement this "within the 38!!*IScontext, which is I assume the context to which thiswhole discussion applies# would be to configure thesubscriber's &+ "if we control it# or his outboundproxy * !-+S+0, to insert something like !-!referred-ServiceFecsGveri=on.com. e could then define filter

criteria at the S-+S+0, to cause the :enhanced callscreening: service to be invoked "i.e., cause theassociated applications to be invoked in some pre-defined manner# based on the presence and of and valuecontained in this header. Seems pretty straight-


11/24

forward to me. +an you help me understand "a# whatwould be a EATTA7 way to implement this "within the38!!*IS context - which would seem to preclude theobvious alternative of setting 7-7I toecsGveri=on.com#, and "b# why implementing it as I

describe, is so threatening to the Internet5

ric @rger posted:7emember that in SI!, treatment e)uals routing. If oneroutes based on !-!referred-Service, it means it is arouting data element.

;et's consider an example of an abstract service youcould offer your subscribers. I will then laterdiscuss the enhanced call screening scenario youmention below.

;et us say this is a service that is associated withthe Ceri=on subscriber.hen the Ceri=on subscriber places a call, thesubscriber wishes the network to execute thissubscribed service. oreover, the service is :hidden,:so the 7e)uest-7I is "I'll argue incorrectly used, butlet us ignore that for a moment# the ultimate target,not the actual target "the application server 7e)uest-7I representing the subscribed service#.

nless the goal is to have the user use one and onlyone device ever, I would offer your thought of having

the !-S+S0 do the work is the right thing. oreover,if the !-S+S0 computes a service, it will be computinga !-&sserted-Service, as the !-S+S0 is doing theasserting. This is one of the uses of !-&sserted-Service.


12/24

oreover, if your proprietary device is smart enough toinsert a !-&sserted-Service header, it is smart enoughto rewrite the 7e)uest-7I to point to the real7e)uest-7I and populate the parameters or however elseyou define the application to properly route and handle

the call. o need for proprietary !-&sserted-Servicevalues, and it even gets to route to wherever it needsto go. @ou get to support service bureaux for free,without having to re-write your IS core.

&s the document says, !-&sserted-Service will not routeacross administrative domains, which is the behavioryou want, anyway. oreover, the right treatment willhappen when the re)uest gets to the Ceri=on network,which is &;S/ what you want to have happen. It ishighly likely for a foreign network to strip the !-!referred-Serivce, in which case the service will fail.If you do the !-&sserted-Service calculation at the !-

S+S0, which, by the way, should be dipping the 6SS toverify the subscriber should have access to thepreferred service anyway. /therwise, why bother with a!-S+S05 Said differently, having the !-S+S0 determinethe service IS AH&+T;@ T6A S&A AT/7? T7&00I+ &4 +!S&8A as having the client indicate a preferredservice. Eetter yet, there is no opportunity forfraud, mistakes, and upgrades can happen in acentrali=ed fashion, instead of having to upgrade allof your proprietary clients.

In this example, the damage to the Internet of using !-!referred-Service is the protocol is no longer SI!.

7ather than routing to the re)uested 7e)uest-7I, theprotocol is subverted to route based on !-!referred-Service. SI! does not work that way. oreover, thetemptation becomes to do all routing based on !-!referred-Service, at which point why bother with all


13/24

of the overhead of SI!

Tim 4wightThanks for the reply. The exchange has helped me a

lot. 6ere's where I've got to in my own thinking, withyour kind assistance

- I am unconvinced that I have any need for * use for,!-&sserted-Service.

- The usage I see for !-!referred-Service is to:influence: the service that is invoked through the normal service selectionmechanism. In other words, however that works, I don't want !-!referred-Service tochange its result.Eut I

would like to be able to :pass a parameter to: theresulting service, to cause it to behave differently. I see this aspotentially useful, when the function I'm trying to invoke is not implemented in aseparate application server but rather exists as :conditional code: withinan application server. I offer the example of a :DoS monitor: function,below.

That is of some use even if it can't be passed acrossnetwork boundaries,

but would be more useful if it could. &ny chance ofchanging the encoding to allow this5

I accept that that usage may not be intuitive given


14/24

the header name we've selected :!-!referred-Service:. aybe what I'mimagining is really some 3rd thing, not !-&sserted-Service and not !-!referred-Service. If it's a

useful thing "I'm of course interested in your viewsthere# maybe it could be advanced on its own.

ore commentary is inserted inline, below.

I don't know what :treatment e)uals routing: means. Ialso don't know that I "or anyone# wants to route "inthe sense of determining an inter-network-element path#based on !-!referred-Service. I guess any parameterwhose value is evaluated could be said to :dispatch:the associated logic, and therefore be said to be arouting data element - the result being that virtually

all parameters are so categori=ed. I suspect there'ssomething I'm missing here.

8iven the common use of retargetting, you sorta have tosay where "at what interface# you're talking about.It doesn't strike me as wrong that the 7-7I insertedby the originating A would be as you describeB in ISthat would be common. In pre-IS networks "at leastthe ones we've built# the A is configured to populate7-7I with the 0D4 of the &S instance at which thesubscriber's service data is provisioned. The latterseems to be what you're regarding as correct. I wouldargue that either can be correct depending on context.

y notion was to insert a provisioned value that ismeaningful in the subscriber's home network, but nototherwise standardi=ed. I don't think that would be anappropriate usage of !-&sserted-Service. I can think


15/24

of examples where it's best that the A insert it"e.g., where its value is based on the context in whichthe re)uest is made# and examples where it's best thatthe !-+S+0 insert it "e.g., if its effect is to invokea capability in the network that the subscriber

wouldn't voluntarily re)uest, wouldn't be allowed tore)uest, wouldn't understand, etc.,#. &n example ofthe latter might be a :DoS monitor:that we could invoke on behalf of subscribers whoreport service problems, or use for statisticalsampling of network performance.

@ou assume that there is a :real 7e)uest-7I: that canin all cases be used to convey the desired networkbehavior. I don't know that that's the case. In the:DoS onitor: example above, I don't want the messageto be routed any differently than it normally would be.I only want to invoke some additional logic within the

application servers that normally process this type ofcall. It's possible that not all of them have suchlogicB in which case I would want them to ignore !-!referred-Service.

I'm unconvinced that I have any use for !-&sserted-Service. It would be helpful for !-!referred-Serviceto be carried across administrative domains, ignoredwhere not understood. I'm not sure the proposed 7coding is ade)uate - seems like a 7I would be betterin this respect.If the host part identified a domain for which theentity that owns the device examining the header is not

authoritative, the value would be ignored.

That would be nice -#

In the examples I have in mind, the service wouldn't


16/24

fail but the :extra function: I intended to trigger byincluding !-!referred-Service, wouldn't get triggered.hich is unfortunate, and if there were a way to makeit work in roaming scenarios I'd certainly prefer that.

The !-+S+0 does not interface to the 6SS. Eut anyway Ihave no interest in !-+S+0 :calculating: !-&sserted-Service, nor any use for !-&sserted-Service generally.

I don't see much value in any element :calculating theservice:. This whole concept is useless in IS, wheredetermination of the service must involve access to *evaluation of, filter criteria.

&t this point, the only thing of value I see here isthe ability to insert via the !-!referred-Serviceheader a value that can :influence:the service, as illustrated in the :DoS onitor:

example above.

aybe in someone else's preferred usage that is thecase. ot in mine.

That )uestion does come up a lot... 6.3%3 is lookingbetter all the time-#

That's interesting but not what I had in mind. I meantsomething a lot simpler - e.g., to block access tocertain numbers. Imagine a parent who wants their homephone not to have access to J99 numbers while the kids

are at home unsupervised. That sort of thing. To behonest I didn't think deeply about this. If I had agreat new service idea I would probably not describe ithere anyway -#


17/24

I don't know that the term :enhanced call screening:has a standard meaning. If it does, and I've used itincorrectly, my apologies.

@es, an outbound screening service was what I had in

mind.

Aric Eurgero worries.

The DoS monitoring tag is (precisely( why !-!referred-Service is not the way to go. hat you would like isan indicator for network elements that may understandthe indicator to make DoS measurements, and possiblyreport on them.

That is not !-!referred-Service. That would besomething like :record-)os

true: or :record-)oshttps**deepinthenetwork.veri=on.net*customer5unameFdtwK%averi=on.comLcallidFaMJ%39M$==):

It would be useful to standardi=e that function, somultiple, interoperable implementations could be doneso service providers could buy standard e)uipment,instead of proprietary, network-specificimplementations.

oreover, what happens when one has another usefulthing that wants to use !-!referred-Service5

;astly, would you not want this to have the samemeaning to all parties, not >ust in the Ceri=onnetwork5 hen the Ceri=on subscriber calls customerservice because of poor )uality results, it will not
https://deepinthenetwork.verizon.net/customer?uname=dtw*verizon.com&callidhttps://deepinthenetwork.verizon.net/customer?uname=dtw*verizon.com&callidhttps://deepinthenetwork.verizon.net/customer?uname=dtw*verizon.com&callidhttps://deepinthenetwork.verizon.net/customer?uname=dtw*verizon.com&callid


18/24

make them happy to hear, :ell, we know it is notCeri=on.: It is much more believeable to say, :e knowit is not Ceri=on, and there are problems identified inthe +ox network.:

Said differently, as you point out, this may very wellwant a new header.4o not make that header !-!referred-Service.

0or arguments sake, let us say that to indicate DoSmonitoring, it takes two SI! headers and three S4!parameters, all taken together to mean :monitor thisdialog.: This is the >ustification for !-&sserted-Service. 7ather than have every network element parsethe entire ICITA and calculate whether or not to doDoS monitoring, you can have your ingress point do thecalculation once and then insert the !-&sserted-Serviceheader. That way the other network elements do not

need to do the calculation, greatly increasing thescale of your core network processing capability.

/n the call blocking example, we are again using thewrong tool. There are two places to block the calls,in the user e)uipment or in the network. The !-!referred-Service proposal does neither.

If the handset is smart enough to insert :!-!referred-Service Elock-J99:, it is smart enough to simply blockJ99N calls. The problem is, that feature is device

specific. Trust me, it would take a 2$-year-old about21 minutes to figure that out.

Thus, what you want is a network-based service.oreover, you want a network-based service that works


19/24

will all of the subscriber's devices, now and into thefuture, /T a particular piece of e)uipment or terminaladapter "too easy to circumvent#.

This is a classic case for a E%E&. ost often, this

would be a !-S+S0 "SE+#, but could be service logicexecuted at the S-S+S0 or S+I. The point is one wantsthe service logic applied to all re)uests by the user,not by all re)uests from a particular device.

&gain, this highlights the danger of !-&sserted-Service. hile it looks like it might work for thecall blocking case, it turns out it does not work atall.

;ooking at some of the comments below, it looks likewhat we really want is some way to pass parameters from

end-to-end, the second end being the applicationserver"s#. That would not be !-!referred-Service, asthat would have serious name collision potential as thedraft is now written. 6owever, such a facility wouldbe hugely useful. I would have loved to have such afacility for 70+ $%$9, for example. That may be evenmore work worth doing.

?eith two more work items5 -#

Tim !ight:aybe so, for someone else's definition of thiscapability. 0or mine, I'm only hoping to communicateto the application server"s#. It's possible that thisexample is so universal that the indicator used toinvoke it should be standardi=ed. o problem. Eutit's also possible that this "or other# capabilitiesare less universal, and most expedient to support on a


20/24

network-specific basis. +ertainly I think it wouldhinder innovation if every parameter one wished to passto an application server had to be standardi=ed.

e all like it both ways -# e like and benefit fromstandardi=ation, but also seek ways to differentiate.

Seems to me this is a coding issue. e could allowmultiple instances of the header, or allow the headerto communicate multiple values. I think the moreinteresting )uestion is how we avoid collision between"a# networks and "b# applications within a network.

In the example I cited, the application whose behaviorwas to be influenced by the value encoded in !-!referred-Service, is in the home network.

I am not opposed to a standardi=ed :record-)os: typeheader, as you suggest above. !ractically speaking Ithink it would be hard to convince operators to sharenetwork impairment information. In the end we'dprobably benefit, but it's not in our nature -# Eutanyway that's a different capability

I understand the theory but am unconvinced by theexamples. If we have designed the signaling such thatthese 1 parameters >ointly mean one thing, and don'tindividually have any other purpose, then we'vedesigned it badly. e should >ust signal the onething. The more likely case is that they do haveindividual meanings, or meanings when grouped withother parameters, and for that reason they'd have to beevaluated whether or not !-&sserted-Service is present.

@ep, in that case the parameter would need to beinserted by the network on behalf of the user. That's


21/24

not the only use case for the capability I have in mind":tunneling: a parameter to an app server to influenceits behavior#, though maybe it's the dominant one inpractice. I wouldn't want to preclude that the Ainserts the parameter, because there might be

interactions between the application initiating thesession re)uest and the application server in thenetwork, that devices downstream of the A wouldn'tknow.

I agree that were this capability one we're imposing onthe customer we'd want to do it in a device to which hehas no access, but not all capabilities we might liketo support fall in that category. 0or some conceivableusages, the invocation (has( to come from the A,because no device other than the A knows what value toassert.

Sometimes. 4epends on what the service logic is. Iwouldn't rule out that it could be device or end-user-application -specific.

@es.

Sign me up -#

15 eneral ,tle @onrad /n draft-drage-sipping-service-identification-92 Iwould like to ask wheter it would be more beneficial toleave out the registration 7-namespace registration

and only point to e.g. 70+ %2$2.

This would make the draft focusing on the usage of the!-headers, which I think is fine. The draft would also

=4T S467


22/24


23/24

rather secure that the draft can be completed timelywith the needed flexibility.

16 "hri#terAol!0er'

The draft now says that the &E0 can be used both forservices and applications, which is good.

6owever, the &E0 still contains the '(":-:application-id#' part, which I don't think is needed.

#i(ed.

17 "hri#terAol!0er'

/ne of the issues below we discussed in Cienna, so it'shere >ust as a reminder. The second issue I believe is:new:.

0irst, I think the (":-:application-id# part of the&E0 shall be removed "since the 7 itself can be anapplication id#, and my understanding from Cienna isthat you agreed to that.

Second, chapter M.% now defines :3gpp-service: and

:3gpp-application:.6owever, the &E0 does not allow the :-: character fortop-level, so that needs to be changed.

So

let-dig F &;!6& * 4I8IT

...should be something like

let-dig F &;!6& * 4I8IT * :-:

#i(ed as proposed.

1: "hri#ter

Aol!0er'

&nd a third issue. The &E0 says

Service-I4 F :urnxxx: urn-service-id

Eut, I think the agreed correct syntax shall be

ithdra!n $y

commentor


24/24

Service-I4 F :urnxxx.: urn-service-id

...ie a 4/T after :xxx:, instead of +/;/.

0orget my third issue. It shall be :xxx:

1; "hri#terAol!0er'

& new third issue

The &E0 says

:urnxxx:

Eut, according to 70+ 3$9O the informal I4 shall havea :urn-xxx:format.

So, the correct syntax should be

:urnurn-xxx:

...which is also the value used in the 38!!specifications.

#i(ed

2- Ian %har& B#t a #hort note to let yo kno$ thi# reference i# $ron' in yor draft.

'%) Aennings8 C.8 ,eterson8 A.8 and B. atson8 "#C 33&3: ,rivate

(tensions to the Session +nitiation ,rotocol S+, for sserted

+dentity !ithin Trsted =et!or/s"8 =ovem$er &00&.

The #C nm$er shold $e #C 33&5.

#i(ed

service id comments

Documents