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 you mean RFC 3325 in this reference and also where the reference is made Section 2 2nd paragraph.

The only comment from my previous list which does not appear in the new version is the correction to the RFC number in Ref 6. This should be 3325.

 

Fixed

 

3

4.1, 5.1.2

Context

Ian Elz

In Sections 4.1 and 5.1.2 you mention P-Asserted-Identity. I do not see the context of the reference to these headers in this draft or in the positions in which they are include din the draft.

Fixed already in -01

4

General

Open issues

Ian Elz

There are 3 remaining open issues in the draft. I am unsure if these need to be resolved before the draft can reach RFC status.

Fixed already in -01

5

1

Open issues

Ian Elz

OI1 - Introduction - What is a service ?

Is a definition of the term service really required in this document. From my reading of the document the intent is to define headers which will enable a service identity to be passed in a SIP Request and to define a structure which will allow registration of the identities of the services. The definition of a service is outside this scope. While the definition of a service is interesting it is not a key aspect of this document.

Proposed Text:

The definition of the term service is outside the scope of this document. Separate activity is being undertaken to resolve this issue. This document limits its scope to defining the headers necessary to passing of the service identity and the structure for defining the service identities.

Fixed already in -01. Reference is made to draft-ietf-sipping-service-identification as the basis for this.

6

1

Open issues

Ian Elz

OI2 - Introduction - Reference to proposed SIPPING document.

Is this reference required. The note above is quite explicit in stating that extension of SIP may be required to allow for identification of a particular service. This fact should be enough.

Reference continues – see above for definition of service.

7

4.3

Open issues

Ian Elz

OI3 - Section 4.3 - Service Identifier and Application Identifiers.

I am unsure that what is here is actually an issue and it could be rewritten as a statement rather than an issue.

Proposed Text:

The syntax defined below provides the capability to distinguish between service identifiers and application identifiers.

It is currently not clear whether this capability is needed but the ability to use this capability adds flexibility to the definition.  If the sole purpose is to identify a particular API within the end terminal, then it may well be that the extensions provided by [11] fulfils this purpose within the genuine usage of a media feature tag.

No distinction is now made in the text between services and applications. Different identifier roots are provided within the URN however.

8

General

 

Ian Elz

There are also a couple of references [xx] where you have the references listed in the document.

Fixed

9

General

 

Barry Leiba (Security directorate)

I have to say up front that I'm very unhappy with this document.  It doesn't say what its status is, but I see from the tracker that it's informational, not standards-track.  Still, it seems to provide very little information, and waves its hands about too many things.

category="info" added to top of document.

10

1

 

Barru Leiba (Security directorate)

It also has enough problems with grammar that I'm often not sure what it's trying to say.  The very first sentence of the introduction, for example:

 

   This document describes private extensions to the Session Initiation

   Protocol (SIP) that enable a network of trusted SIP servers to assert

   the service and for users entitled to that service.

 

I can't parse that sentence, and I don't know what it means to say.  Similarly for the beginning of section 4.2:

 

   The P-Preferred-Service header field is used from a user agent to a

   trusted proxy to carry the preferred service of the user sending the

   SIP message wishes to be used for the P-Asserted-Service field value

   that the trusted element will insert.

 

It's hard to decide on the technical content of a document when there are what seem to be key bits that aren't readable.

 

Introduction changed to: "This document describes private extensions to the Session Initiation Protocol (SIP) that enable a network of trusted SIP servers to assert the service possibly subject to the user being entitled to that service.  "

 

4.2 modified to: " The P-Preferred-Service header field is used from a user agent to a trusted proxy to carry the preferred service of the user sending the SIP request that the user wishes to be used for the P-Asserted-Service field value that the trusted element will insert."

11

General

 

Barry Leiba (Security directorate)

What I *can* understand seems to be missing a lot.  It seems to me that this document is basically defining two new SIP header fields, P-Asserted-Service and P-Preferred-Service.  The document is very vague -- necessarily so, it says -- about the actual usage of these fields, and that's the second thing that makes me unhappy with publishing this.  The vagueness results in my not understanding what it is that these fields are used to assert or request, why and when a SIP request would want/need to use these (and when it wouldn't), and what, exactly, happens when they're used.  I can't imagine that an implementor who didn't already know what was going on would get things right based on reading this document.  And my experience with even simple protocol standards is that there are many implementors who get things wrong even when the specs are clearly written -- and SIP is not a simple standard.

TO RESOLVE

12

Security considerations

 

Barry Leiba (Security directorate)

The third thing that bothers me is that the Security Considerations section blows off all considerations, even though there are many references in the document to security-related issues.  Trust domains are talked about often, and there are MUST and MUST NOT requirements for passing around information and credentials.  None of that is brought up as a security consideration.  For example, here's something, in section 5.1.3, that I think has to be discussed in the security considerations section:

 

   If a UA is part of the Trust Domain from which it received a request

   containing a P-Asserted-Service header field, then it can use the

   value freely but it MUST ensure that it does not forward the

   information to any element that is not part of the Trust Domain.

 

What happens if it does forward this information?  How does it know what elements are part of the trust domain?  Can the composition of the trust domain change over the life of a SIP request/session?  How can a trust domain rely on the actions of a user agent?  What if a malicious user tampers with the user agent, which is, after all, under his control?  How does the trust domain defend itself against that?  Why are security-sensitive itens entrusted to a user agent in the first place?

 

There may be reasonable answers to these sorts of questions, but there's nothing at all about them in the security considerations.

 

All in all, I think this document needs significant work before it's ready to be published.

 

Following paragraph added to service considerations:

"The trust domain provides a set of servers where the characteristics of the service are agreed for that service identifier value, and that the calling user is entitled to use that service. draft-ietf-sipping-service-identification <xref target="I-D.draft-ietf-sipping-service-identification" /> identifies the impact of allowing such service identifier values to "leak" outside of the trust domain, including implications on fraud, interoperability and stifling of service innovation."

13

General

 

Salvatore Loreto

as maybe you have noticed, a draft asking the registration of a specific URN namespace for general use bye 3GPP has been submitted (draft-monrad-sipping-3gpp-urn-namespace-00.txt).

Now, even if the draft is not specific for service identification, but has a larger applicability, I do think that the Service-identification draft has to take it in consideration.

 

In fact, the present version of the drage-sipping-service-identification

draft defines a new registry called "Service-ID/Application-ID Labels", claiming that creating a new service at the top-level requires a IANA action.

 

However the service-identification draft describes a *private extension* to the SIP that enable a network or trusted SIP servers (like 3GPP) to assert the service of authenticated users.

So I do really think that these private networks should have the freedom to define an its own *private* label that define a service, especially if you consider that this label is thought to be used only within the private networks.

 

Really, I don't understand why something that should be used only within private/trusted network, like 3GPP, should require the usage of a IANA registered label.

Ted Hardie commented:

> I'm a wee bit confused by your comments here.  Can you clarify what

> the 3gpp NID proposal does here that worries you?  Organizational

> namespaces aren't exactly rare in the URN registry:  iso, oma even xsf.

> 3gpp looks to be asking for a very general entry of the same type, at

> least if I'm reading the namespace considerations correctly.

Salvatore Loreto responded:

I am totally in favor of a 3gpp NID proposal.

in fact I am just asking Keith to modify the service-identification draft and let possible the usage of Organizational namespace.

 

At present in the Keith draft *creating a new service at the top-level requires a IANA registration*.

 

NOT RESOLVED

14

General

 

Eric Burger

The mechanisms described in the draft for the P-Asserted-Service makes sense and is useful.  My only comment with P-Asserted-Service is I would STRONGLY RECOMMEND an IESG note on the cover of the draft warning of the dire consequences of relying on the P-Asserted-Service between administrative domains or between a SIP User Agent Client and the network.

 

However, the mechanisms described in the draft for P-Preferred-Service have no utility and, in fact, may result in harmful behavior.

 

To wit, consider the following section from the draft:

   5.1.1. Procedures at User Agent Clients (UAC)

 

   The UAC MAY insert a P-Preferred-Service in a request that creates a

   dialog, or a request outside of a dialog.  This information can

   assist the proxies in identifying appropriate service capabilities to

   apply to the call.  This information MUST NOT conflict with other SIP

   or SDP information included in the request.  Furthermore, the SIP or

   SDP information needed to signal functionality of this service MUST

   be present.  Thus if a service requires a video component, then the

   SDP has to include the media line associated with that video

   component; it cannot be assumed from the P-Preferred-Service header

   field value. Similarly if the service requires particular SIP

   functionality for which a SIP extension and a Require header field

   value is defined, then the request has to include that SIP signalling

   as well as the P-Preferred-Service header field value.

 

 

What this says is all of the information required to route the call (i.e., determine the service) is contained in the INVITE message.  Stated differently, the P-Preferred-Service header PROVIDES NO USEFUL INFORMATION.

To date, in discussions in the SIPPING Work Group, there have been virtually no service examples for which the P-Preferred-Service header adds any information.  In fact, the examples for which the P-Preferred-Service header added value highlight why this header will be detrimental to the Internet.

Namely, the use cases where it does add information are cases where the SIP protocol itself is deficient.

 

What makes this use detrimental is the P-Preferred-Service approach is, by definition, proprietary and non-interoperable.  Rather than repairing or extending the base protocol, this header will encourage "quick fixes" that do not address the underlying problem.  At that point the P-Preferred-Service takes on protocol meaning, EVEN OUTSIDE A LIMITED DOMAIN.  The problem is this protocol meaning is proprietary and by definition non-interoperable.  Moreover, the draft presents no negotiation mechanism, nor do I see how there could possibly be a negotiation mechanism.

Standard SIP user agents and proxies will not be able to negotiate common communication parameters if a key protocol element is proprietary.

 

Moreover, use of the P-Preferred-Service in this manner will encourage proxies and user agents to not bother to parse and interpret the existing information contained in the SIP INVITE.  At this point, the protocol is no longer SIP.

 

To reiterate, I have no problem with the publication of P-Asserted-Service, as defined in the above named draft, as an IETF-reviewed publication.

 

However, I would strongly object to the publication of P-Preferred-Service as an IETF reviewed publication.  It presents a clear and present danger to the Internet, and could potentially end the possibility of having interoperable communications in the Internet.

 

Tim Dwight posted:

Apparently you feel strongly about this, but I don't understand what you're saying.  I thought I'd try and clarify what I'm missing, before posting to the list and being "repeatedly educated".

 

First with respect to the mechanisms defined in 5.1.1 which you say "have no utility and, in fact, may result in harmful behavior."

 

You indicate that "What this says is all of the information required to route the call (i.e., determine the service) is contained in the INVITE message.  Stated differently, the P-Preferred-Service header PROVIDES NO USEFUL INFORMATION."

 

Questions:

 

1) is "routing the call" synomymous with "determining the service"?

Consider an analogy with diffserv.  The DSCP does not affect the routing of the packet but it may influence the way the packet is handled by the routers traversed (i.e., the "service" provided at L3, to the packet).

Hence it seems there is precedent for separating service and routing.

Moreover the interpretation of DSCP (mapping to PHB etc.,) is defined only within an administrative domain, which some might call "proprietary and non interoperable".  Yet we accept it, we've deployed it, the Internet didn't break.  Why was it OK in that case to distinguish service from routing, and define service such that its meaning may be different in different administrative domains, but not OK in this case?

Or is that a misunderstanding on my part, of what P-Preferred-Service is meant to achieve?

 

2) You seem to be arguing that P-Preferred-Service can only be a summarization of information that must be elsewhere in the packet.  I don't read it that way.  I read it to say that P-Preferred-Service cannot contradict information elsewhere in the packet, nor can it be used instead of information for which a standard representation is defined.  But I don't understand this to mean that P-Preferred-Service cannot provide additional information.

 

 

An example.  Suppose Verizon offers an "enhanced call screening" service to its VoIP subscribers.  Suppose that the network's implementation of this service involves invocation of a collection of functions spread over a collection of application servers.  A straight forward way to implement this (within the 3GPP/IMS context, which is I assume the context to which this whole discussion applies) would be to configure the subscriber's UAC (if we control it) or his outbound proxy / P-CSCF, to insert something like P-Preferred-Service=ecs@verizon.com.  We could then define filter criteria at the S-CSCF, to cause the "enhanced call screening" service to be invoked (i.e., cause the associated applications to be invoked in some pre-defined manner) based on the presence and of and value contained in this header.  Seems pretty straight-forward to me.  Can you help me understand (a) what would be a BETTER way to implement this (within the 3GPP/IMS context - which would seem to preclude the obvious alternative of setting R-URI to ecs@verizon.com), and (b) why implementing it as I describe, is so threatening to the Internet? 

 

 

Eric Burger posted:

Remember that in SIP, treatment equals routing.  If one routes based on P-Preferred-Service, it means it is a routing data element.

 

Let's consider an example of an abstract service you could offer your subscribers.  I will then later discuss the enhanced call screening scenario you mention below.

 

Let us say this is a service that is associated with the Verizon subscriber.

When the Verizon subscriber places a call, the subscriber wishes the network to execute this subscribed service.  Moreover, the service is "hidden," so the Request-URI is (I'll argue incorrectly used, but let us ignore that for a moment) the ultimate target, not the actual target (the application server Request-URI representing the subscribed service).

 

Unless the goal is to have the user use one and only one device ever, I would offer your thought of having the P-SCSF do the work is the right thing.  Moreover, if the P-SCSF computes a service, it will be computing a P-Asserted-Service, as the P-SCSF is doing the asserting.  This is one of the uses of P-Asserted-Service.

 

Moreover, if your proprietary device is smart enough to insert a P-Asserted-Service header, it is smart enough to rewrite the Request-URI to point to the real Request-URI and populate the parameters or however else you define the application to properly route and handle the call.  No need for proprietary P-Asserted-Service values, and it even gets to route to wherever it needs to go.  You get to support service bureaux for free, without having to re-write your IMS core.

 

As the document says, P-Asserted-Service will not route across administrative domains, which is the behavior you want, anyway.  Moreover, the right treatment will happen when the request gets to the Verizon network, which is ALSO what you want to have happen.  It is highly likely for a foreign network to strip the P-Preferred-Serivce, in which case the service will fail.  If you do the P-Asserted-Service calculation at the P-SCSF, which, by the way, should be dipping the HSS to verify the subscriber should have access to the preferred service anyway.  Otherwise, why bother with a P-SCSF?  Said differently, having the P-SCSF determine the service IS EXACTLY THE SAME NETWORK TRAFFIC AND CPU USAGE as having the client indicate a preferred service.  Better yet, there is no opportunity for fraud, mistakes, and upgrades can happen in a centralized fashion, instead of having to upgrade all of your proprietary clients.

 

In this example, the damage to the Internet of using P-Preferred-Service is the protocol is no longer SIP.  Rather than routing to the requested Request-URI, the protocol is subverted to route based on P-Preferred-Service.  SIP does not work that way.  Moreover, the temptation becomes to do all routing based on P-Preferred-Service, at which point why bother with all of the overhead of SIP

 

 

Tim Dwight:

Thanks for the reply.  The exchange has helped me a lot.  Here's where I've got to in my own thinking, with your kind assistance:

 

- I am unconvinced that I have any need for / use for, P-Asserted-Service.

 

- The usage I see for P-Preferred-Service is to "influence" the service that

  is invoked through the normal service selection mechanism.  In other words, however

  that works, I don't want P-Preferred-Service to change its result.

But I

  would like to be able to "pass a parameter to" the resulting service, to

  cause it to behave differently.  I see this as potentially useful, when the

  function I'm trying to invoke is not implemented in a separate application

  server but rather exists as "conditional code" within an application server.

  I offer the example of a "QoS monitor" function, below.

 

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

  but would be more useful if it could.  Any chance of changing the encoding

  to allow this?

 

  I accept that that usage may not be intuitive given the header name we've

  selected "P-Preferred-Service".  Maybe what I'm imagining is really some

  3rd thing, not P-Asserted-Service and not P-Preferred-Service.  If it's a

  useful thing (I'm of course interested in your views there) maybe it could

  be advanced on its own.

 

More commentary is inserted inline, below.

 

I don't know what "treatment equals routing" means.  I also don't know that I (or anyone) wants to route (in the sense of determining an inter-network-element path) based on P-Preferred-Service.  I guess any parameter whose value is evaluated could be said to "dispatch" the associated logic, and therefore be said to be a routing data element - the result being that virtually all parameters are so categorized.  I suspect there's something I'm missing here.

 

Given the common use of retargetting, you sorta have to say _where_ (at what interface) you're talking about.  It doesn't strike me as wrong that the R-URI inserted by the originating UE would be as you describe; in IMS that would be common.  In pre-IMS networks (at least the ones we've built) the UE is configured to populate R-URI with the FQDN of the AS instance at which the subscriber's service data is provisioned.  The latter seems to be what you're regarding as correct.  I would argue that either can be correct depending on context.

 

My notion was to insert a provisioned value that is meaningful in the subscriber's home network, but not otherwise standardized.  I don't think that would be an appropriate usage of P-Asserted-Service.  I can think of examples where it's best that the UE insert it (e.g., where its value is based on the context in which the request is made) and examples where it's best that the P-CSCF insert it (e.g., if its effect is to invoke a capability in the network that the subscriber wouldn't voluntarily request, wouldn't be allowed to request, wouldn't understand, etc.,).  An example of the latter might be a "QoS monitor"

that we could invoke on behalf of subscribers who report service problems, or use for statistical sampling of network performance.

 

You assume that there is a "real Request-URI" that can in all cases be used to convey the desired network behavior.  I don't know that that's the case.  In the "QoS Monitor" example above, I don't want the message to 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 of call.  It's possible that not all of them have such logic; in which case I would want them to ignore P-Preferred-Service.

 

I'm unconvinced that I have any use for P-Asserted-Service.  It would be helpful for P-Preferred-Service to be carried across administrative domains, ignored where not understood.  I'm not sure the proposed URN coding is adequate - seems like a URI would be better in this respect.

If the host part identified a domain for which the entity 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 fail but the "extra function" I intended to trigger by including P-Preferred-Service, wouldn't get triggered.  Which is unfortunate, and if there were a way to make it work in roaming scenarios I'd certainly prefer that.

 

The P-CSCF does not interface to the HSS.  But anyway I have no interest in P-CSCF "calculating" P-Asserted-Service, nor any use for P-Asserted-Service generally.

 

I don't see much value in any element "calculating the service".  This whole concept is useless in IMS, where determination of the service must involve access to / evaluation of, filter criteria.

 

At this point, the only thing of value I see here is the ability to insert via the P-Preferred-Service header a value that can "influence"

the service, as illustrated in the "QoS Monitor" example above.

 

Maybe in someone else's preferred usage that is the case.  Not in mine.

 

That question does come up a lot... H.323 is looking better all the time

:-)

 

That's interesting but not what I had in mind.  I meant something a lot simpler - e.g., to block access to certain numbers.  Imagine a parent who wants their home phone not to have access to 900 numbers while the kids are at home unsupervised.  That sort of thing.  To be honest I didn't think deeply about this.  If I had a great new service idea I would probably not describe it here anyway :-)

 

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

 

Yes, an outbound screening service was what I had in mind.

 

Eric Burger:

No worries.

 

The QoS monitoring tag is *precisely* why P-Preferred-Service is not the way to go.  What you would like is an indicator for network elements that may understand the indicator to make QoS measurements, and possibly report on them.

 

That is not P-Preferred-Service.  That would be something like "record-qos:

true" or "record-qos:

https://deepinthenetwork.verizon.net/customer?uname=dtw%2averizon.com&callid

=a8923084zzq"

 

It would be useful to standardize that function, so multiple, interoperable implementations could be done so service providers could buy standard equipment, instead of proprietary, network-specific implementations.

 

Moreover, what happens when one has another useful thing that wants to use P-Preferred-Service?

 

Lastly, would you not want this to have the same meaning to all parties, not just in the Verizon network?  When the Verizon subscriber calls customer service because of poor quality results, it will not make them happy to hear, "Well, we know it is not Verizon."  It is much more believeable to say, "We know it is not Verizon, and there are problems identified in the Cox network."

 

Said differently, as you point out, this may very well want a new header.

Do not make that header P-Preferred-Service.

 

For arguments sake, let us say that to indicate QoS monitoring, it takes two SIP headers and three SDP parameters, all taken together to mean "monitor this dialog."  This is the justification for P-Asserted-Service.  Rather than have every network element parse the entire INVITE and calculate whether or not to do QoS monitoring, you can have your ingress point do the calculation once and then insert the P-Asserted-Service header.  That way the other network elements do not need to do the calculation, greatly increasing the scale of your core network processing capability.

 

 

 

On the call blocking example, we are again using the wrong tool.  There are two places to block the calls, in the user equipment or in the network.  The P-Preferred-Service proposal does neither.

 

If the handset is smart enough to insert "P-Preferred-Service: Block-900", it is smart enough to simply block 900# calls.  The problem is, that feature is device specific.  Trust me, it would take a 14-year-old about 15 minutes to figure that out.

 

Thus, what you want is a network-based service.  Moreover, you want a network-based service that works will all of the subscriber's devices, now and into the future, NOT a particular piece of equipment or terminal adapter (too easy to circumvent).

 

This is a classic case for a B2BUA.  Most often, this would be a P-SCSF (SBC), but could be service logic executed at the S-SCSF or SCIM.  The point is one wants the service logic applied to all requests by the user, not by all requests from a particular device.

 

Again, this highlights the danger of P-Asserted-Service.  While it looks like it might work for the call blocking case, it turns out it does not work at all.

 

 

Looking at some of the comments below, it looks like what we really want is some way to pass parameters from end-to-end, the second end being the application server(s).  That would not be P-Preferred-Service, as that would have serious name collision potential as the draft is now written.  However, such a facility would be hugely useful.  I would have loved to have such a facility for RFC 4240, for example.  That may be even more work worth doing.

 

Keith: two more work items?  :-)

 

Tim Dwight:

Maybe so, for someone else's definition of this capability.  For mine, I'm only hoping to communicate to the application server(s).  It's possible that this example is so universal that the indicator used to invoke it should be standardized.  No problem.  But it's also possible that this (or other) capabilities are less universal, and most expedient to support on a network-specific basis.  Certainly I think it would hinder innovation if every parameter one wished to pass to an application server had to be standardized.

 

We all like it both ways :-)  We like and benefit from standardization, but also seek ways to differentiate.

 

Seems to me this is a coding issue.  We could allow multiple instances of the header, or allow the header to communicate multiple values.  I think the more interesting question is how we avoid collision between

(a) networks and (b) applications within a network.

 

In the example I cited, the application whose behavior was to be influenced by the value encoded in P-Preferred-Service, is in the home network.

 

I am not opposed to a standardized "record-qos" type header, as you suggest above.  Practically speaking I think it would be hard to convince operators to share network impairment information.  In the end we'd probably benefit, but it's not in our nature :-)  But anyway that's a different capability

 

I understand the theory but am unconvinced by the examples.  If we have designed the signaling such that these 5 parameters jointly mean one thing, and don't individually have any other purpose, then we've designed it badly.  We should just signal the one thing.  The more likely case is that they do have individual meanings, or meanings when grouped with other parameters, and for that reason they'd have to be evaluated whether or not P-Asserted-Service is present.

 

Yep, in that case the parameter would need to be inserted by the network on behalf of the user.  That's not the only use case for the capability I have in mind ("tunneling" a parameter to an app server to influence its behavior), though maybe it's the dominant one in practice.  I wouldn't want to preclude that the UE inserts the parameter, because there might be interactions between the application initiating the session request and the application server in the network, that devices downstream of the UE wouldn't know.

 

I agree that were this capability one we're imposing on the customer we'd want to do it in a device to which he has no access, but not all capabilities we might like to support fall in that category.  For some conceivable usages, the invocation *has* to come from the UE, because no device other than the UE knows what value to assert.

 

Sometimes.  Depends on what the service logic is.  I wouldn't rule out that it could be device or end-user-application -specific.

 

Yes.

 

Sign me up :-)

 

 

Added the following text to the introduction: " This document also makes use of the terms "derived service identification" and "declarative service identification" as defined in draft-ietf-sipping-service-identification <xref target="I-D.draft-ietf-sipping-service-identification" />.

 

And the following text to the definition of P-Asserted-Service:

" The P-Asserted-Service header field carries information that is derived service identification. While a declarative service identification can assist in deriving the value transferred in this header, this should be in the form of streamlining the correct derived service identification."

 

And the following text to the definition of P-Preferred-Service: " The P-Preferred-Service header field carries information that is declarative service identification. Such information should only be used to assist in deriving a derived service identification at the recipient entity.

"

DO WE NEED FURTHER RESOLUTION

15

General

 

Atle Monrad

On draft-drage-sipping-service-identification-01 I would like to ask wheter it would be more beneficial to leave out the registration URN-namespace registration and only point to e.g. RFC 2141.

 

 

This would make the draft focusing on the usage of the P-headers, which I think is fine. The draft would also be flexible and could be used by other organisations that has their own URN-administration. E.g. OMA which describes their internal URN-structure in RFC 4358. 3GPP is in the process of creating a similar draft that can be found as draft-monrad-sipping-3gpp-urn-namespace. 

 

As the draft-drage-sipping-service-identification-01 currently desribes the top-level URN for 3GPP ("3gpp-service" and "3gpp-application"), URN-administration is as I see it needed anyway for the subservice identifiers and the application identifiers within 3GPP. Further, OMA will as I understand it need to either update Keiths draft or write an OMA-specific draft to include the possible "OMA-service" and "OMA-application" top level URNs. I do not understand the benefit with having the top-level URNs handled by IANA as IANA anyway subcontract the URN administration to other SDOs.

 

By leaving the URN-administration out,

draft-drage-sipping-service-identification would gain flexibility to be used by other organisations as OMA without any additions. As the draft mention POC as a "service" in an example, I would also find it useful that the draft is flexible enough to also cover OMA.

 

My comments mainly concerns the introduction and the clauses 4.3, 4.4 and 8, and can be taken into account without much rewording and does not affect the technical content concerning the definition and usage of P-Preferred-Service and P-Asserted-Service.

 

I fully understand and support the need to expedite the handling of this draft due to 3GPP, but I do not think that this comment will slow down this process, but rather secure that the draft can be completed timely with the needed flexibility.

NOT RESOLVED

16

 

 

Christer Holmberg

The draft now says that the ABNF can be used both for services and applications, which is good.

 

However, the ABNF still contains the '*("-"application-id)' part, which I don't think is needed.

 

Fixed.

17

 

 

Christer Holmberg

One of the issues below we discussed in Vienna, so it's here just as a reminder. The second issue I believe is "new".

 

First, I think the *("-"application-id) part of the ABNF shall be removed (since the URN itself can be an application id), and my understanding from Vienna is that you agreed to that.

 

Second, chapter 8.2 now defines "3gpp-service" and "3gpp-application".

However, the ABNF does not allow the "-" character for top-level, so that needs to be changed.

 

So:

 

let-dig         = ALPHA / DIGIT

 

...should be something like:

 

let-dig         = ALPHA / DIGIT / "-"

 

Fixed as proposed.

18

 

 

Christer Holmberg

And a third issue. The ABNF says:

 

Service-ID      = "urn:xxx:" urn-service-id

 

But, I think the agreed correct syntax shall be:

 

Service-ID      = "urn:xxx." urn-service-id

 

...ie a DOT after "xxx", instead of COLON.

 

Forget my third issue. It shall be "xxx:"

 

Withdrawn by commentor

19

 

 

Christer Holmberg

A new third issue:

 

The ABNF says:

 

"urn:xxx:"

 

But, according to RFC 3406 the informal NID shall have a "urn-xxx"

format.

 

So, the correct syntax should be:

 

"urn:urn-xxx:"

 

...which is also the value used in the 3GPP specifications.

 

Fixed

20

 

 

Ian Sharp

Just a short note to let you know this reference is wrong in your draft.

[6] Jennings, C., Peterson, J., and M. Watson, "RFC 3323: Private Extensions to the Session Initiation Protocol (SIP) for Asserted Identity within Trusted Networks", November 2002.

The RFC number should be RFC 3325.

Fixed