Subject: Re: [Ecrit] draft-ietf-ecrit-additional-data-07

From: Hannes Tschofenig <[email-masked]>
Date: Tue, 30 Apr 2013 00:22:21 +0300

Hi James, 

I am trying to incorporate some of your review comments and I have a couple of questions. 

On Mar 18, 2013, at 5:41 AM, Winterbottom, James wrote:

> Hi Authors,
>  
> I have reviewed this document and have the following comments, some of which I have already posted to the list and have not had a reply to.
>  
> Comments:
> =================
> The term “Service Provider” is used extensively throughout this document but the term doesn’t seem to be obviously defined in the document, nor is there is a reference to an external definition. To add to this, Service Provider is a defined type in section 14.1.2, but used more generally throughout the rest of the document. This needs a clarification.

I searched for an appropriate definition in IETF RFCs and it turns out that others have defined this term either. 

Do you have a recommendation what we should use? Do you think it is really necessary to describe it?

>  
> Section 6.2 seems to conflate several different concepts. I think that this because it bundles access technologies and telephone service type, though I suspect that it doesn’t mean to, but in so doing it left me quite confused and when I tried to describe a DOCSIS, Fibre or DSL service I couldn’t.  Here is a proposal to address the current issues I see with this section:
> 1)      Break up this element into two elements, one called accessTechnology and then a second one looking at any higher-level application run over the access technology, call it applicationType or something similar.
> 2)      Create a registry for accessTechnology at a minimum it would have what is currently under the “Wireless Telephone System” field and I would add:
> a.      Twisted pair
> b.      Coax
> c.      Fibre
> 3)      The other things listed are high-level services most of which are okay except I would change or add the following:
> a.      Drop wireline and call it circuit-switched. This would then allow me to have accessTechnology=GSM, applicationType=circuit-switched
> b.      Add Packet-Data
> As it is currently written this section really only relates to conventional telephony providers which I didn’t think was the only aim of the document.
>  
> I think it would be worth emphasizing in this section that the nature of the physical access technology does not necessarily dictate the mobility of the call.
>  
> In section 6.2, the definition for VoIP needs to be decoupled from the access technology constraints, these are addressed in section 6.3.

I passed this question forward to the NENA additional data group and to the EENA NG 112 group. 

>  
> Section 6.3, for Nomadic, please can you emphasize that it cannot change its point of network attachment. This does not necessarily mean that the device cannot move.

I added this text. 

>  
> Section 6.2 says “VoIP Telephone Service: A type of service that offers communication over internet protocol, such as Fixed, Nomadic,  Mobile, Unknown”. Section 6.3 does not register “Unknown” as an allowable <SvcMobility> value, yet section 6.4 requires the <SvcMobility> element to be included in the <emergencyCall.SvcInfo> element. I think that it needs to include a value of unknown in the <SvcMobility> register.

I added the "Unknown" category. 

>  
> Section 8.2. This schema has a sequence with one element in it, and this element is optional. This doesn’t make much sense.
>  
With the added extension point there may be more elements in there in the future. 

> None of the schemas have extension points. While some of the discourse on the list over the last few days might suggest that this was deliberate, the discussion as I have followed it has been more to do with adding new blocks than it has been to allowing localized extensions to already defined blocks.
Brian added those; will double-check. 

>  
> NITS
> =====
> Page 5 second paragraph has a PDIF-LO rather than a PIDF-LO

fixed. 

Ciao
Hannes

>  
>  
> Cheers
> James
> _______________________________________________
> Ecrit mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ecrit

---

From: Gunnar Hellstrom <[email-masked]>
Date: Tue, 30 Apr 2013 08:18:36 +0200

------------------------------------------------------------------------
Gunnar Hellström
Omnitor
[email-masked]
+46708204288
> Do you have a recommendation what we should use? Do you think it is really necessary to describe it?
I had a similar problem in another SDO recently. I used "service 
provider" or "communication service provider" for an organization 
handling calls and subscribers.
The conclusion there was to change it to "Application Service Provider" 
with the following definition:

*"Application Service Provider (ASP): *organization or entity that 
provides application-layer services, which may include voice, video and 
text communication"

The reason for confusion was apparently that some thought of the network 
access service provider while others thought about the call control 
service provider when using the term "service provider".

It stands out clear in section14.1.2. that it is a problem.
The table with service provider types contains "service provider" as one 
of the types.

At least this recursive use of the term needs to be broken.

I briefly checked RFC 6881 and RFC 4504 to check how they handled 
"service provider" and found that you are in good company. The term is 
just used without definition and seems to mean an organization working 
on the SIP or other call control level and manages subscribers.

I suggest that this definition is used:

*"Application Service Provider (ASP): *organization or entity that 
provides application-layer services, which may include real-time 
communication"

And then check through the occurrences and replace the ones that have 
the narrow meaning of "Application Service Provider".

/Gunnar

---

From: Brian Rosen <[email-masked]>
Date: Tue, 30 Apr 2013 09:59:50 -0400

I have a problem with "packet data" as a high level service.  That's really a low level service grouping (DSL, FTTH), not a high level service.  Vonage, AIM, Google Talk, those are the high level services, and none of them are "packet data".

Brian

---

From: "Winterbottom, James" <[email-masked]>
Date: Wed, 1 May 2013 06:58:49 +0800

I think you are hung-up on the term high-level, my implication is more that these are higher-level than FTTH, coax, twisted-pair, GSM, UMTS.

What I want/need the distinction between is a packet service and a circuit service both of which can run on the same kind of "physical" access. My 3G UMTS-based phone can operate in circuit-switched mode for calls or in HSDPA+ packet-mode for data services. Both of these come from the same operator. My iPad however is HSDPA+ only, and so is only a packet device.

This differentiation cannot be cleanly represented in the current representation.

What I tried to provide was a way to represent this, I am open to other representations providing they don't ram them all into the same enumerated type.

Cheers
James

-----Original Message-----
From: Brian Rosen [mailto:[email-masked]] 
Sent: Wednesday, 1 May 2013 12:00 AM
To: Hannes Tschofenig
Cc: Winterbottom, James; [email-masked]
Subject: Re: [Ecrit] draft-ietf-ecrit-additional-data-07

Brian
On Apr 29, 2013, at 5:22 PM, Hannes Tschofenig <[email-masked]> wrote:

>> The term "Service Provider" is used extensively throughout this document but the term doesn't seem to be obviously defined in the document, nor is there is a reference to an external definition. To add to this, Service Provider is a defined type in section 14.1.2, but used more generally throughout the rest of the document. This needs a clarification.
> 
>> Section 6.2 seems to conflate several different concepts. I think that this because it bundles access technologies and telephone service type, though I suspect that it doesn't mean to, but in so doing it left me quite confused and when I tried to describe a DOCSIS, Fibre or DSL service I couldn't.  Here is a proposal to address the current issues I see with this section:
>> 2)      Create a registry for accessTechnology at a minimum it would have what is currently under the "Wireless Telephone System" field and I would add:
>> a.      Twisted pair
>> b.      Coax
>> c.      Fibre
>> As it is currently written this section really only relates to conventional telephony providers which I didn't think was the only aim of the document.
>> 
>> Section 6.2 says "VoIP Telephone Service: A type of service that offers communication over internet protocol, such as Fixed, Nomadic,  Mobile, Unknown". Section 6.3 does not register "Unknown" as an allowable <SvcMobility> value, yet section 6.4 requires the <SvcMobility> element to be included in the <emergencyCall.SvcInfo> element. I think that it needs to include a value of unknown in the <SvcMobility> register.
> 
>> Section 8.2. This schema has a sequence with one element in it, and this element is optional. This doesn't make much sense.
>>

---

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Tue, 30 Apr 2013 23:42:52 +0000

Is it a clean differentiation.

Your 3G phone currently can handle emergency data using a modem running over the CS domain and you 3G phone can also support voice services using IMS over GPRS.

Keith

> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Winterbottom, James
> Sent: 30 April 2013 23:59
> To: Brian Rosen; Hannes Tschofenig
> Cc: [email-masked]
> I think you are hung-up on the term high-level, my implication is more
> that these are higher-level than FTTH, coax, twisted-pair, GSM, UMTS.
> 
> What I want/need the distinction between is a packet service and a circuit
> service both of which can run on the same kind of "physical" access. My 3G
> UMTS-based phone can operate in circuit-switched mode for calls or in
> HSDPA+ packet-mode for data services. Both of these come from the same
> operator. My iPad however is HSDPA+ only, and so is only a packet device.
> 
> What I tried to provide was a way to represent this, I am open to other
> representations providing they don't ram them all into the same enumerated
> type.
> 
> Cheers
> James
> 
> 
> 
> I have a problem with "packet data" as a high level service.  That's
> really a low level service grouping (DSL, FTTH), not a high level service.
> Vonage, AIM, Google Talk, those are the high level services, and none of
> them are "packet data".
> 
> Brian
> >> I have reviewed this document and have the following comments, some of
> which I have already posted to the list and have not had a reply to.
> >>
> >> Comments:
> >> =================
> >> The term "Service Provider" is used extensively throughout this
> document but the term doesn't seem to be obviously defined in the document,
> nor is there is a reference to an external definition. To add to this,
> Service Provider is a defined type in section 14.1.2, but used more
> generally throughout the rest of the document. This needs a clarification.
> >
> > I searched for an appropriate definition in IETF RFCs and it turns out
> that others have defined this term either.
> >
> >> Section 6.2 seems to conflate several different concepts. I think that
> this because it bundles access technologies and telephone service type,
> though I suspect that it doesn't mean to, but in so doing it left me quite
> confused and when I tried to describe a DOCSIS, Fibre or DSL service I
> couldn't.  Here is a proposal to address the current issues I see with
> this section:
> >> 1)      Break up this element into two elements, one called
> accessTechnology and then a second one looking at any higher-level
> application run over the access technology, call it applicationType or
> something similar.
> >> 2)      Create a registry for accessTechnology at a minimum it would
> have what is currently under the "Wireless Telephone System" field and I
> would add:
> >> a.      Twisted pair
> >> b.      Coax
> >> c.      Fibre
> >> 3)      The other things listed are high-level services most of which
> are okay except I would change or add the following:
> >> a.      Drop wireline and call it circuit-switched. This would then
> allow me to have accessTechnology=GSM, applicationType=circuit-switched
> >> b.      Add Packet-Data
> >> As it is currently written this section really only relates to
> conventional telephony providers which I didn't think was the only aim of
> the document.
> >>
> >> I think it would be worth emphasizing in this section that the nature
> of the physical access technology does not necessarily dictate the
> mobility of the call.
> >>
> >> In section 6.2, the definition for VoIP needs to be decoupled from the
> access technology constraints, these are addressed in section 6.3.
> >
> >> Section 6.3, for Nomadic, please can you emphasize that it cannot
> change its point of network attachment. This does not necessarily mean
> that the device cannot move.
> >
> > I added this text.
> >
> >>
> >> Section 6.2 says "VoIP Telephone Service: A type of service that offers
> communication over internet protocol, such as Fixed, Nomadic,  Mobile,
> Unknown". Section 6.3 does not register "Unknown" as an allowable
> <SvcMobility> value, yet section 6.4 requires the <SvcMobility> element to
> be included in the <emergencyCall.SvcInfo> element. I think that it needs
> to include a value of unknown in the <SvcMobility> register.
> >
> >> Section 8.2. This schema has a sequence with one element in it, and
> this element is optional. This doesn't make much sense.
> >>
> >> None of the schemas have extension points. While some of the discourse
> on the list over the last few days might suggest that this was deliberate,
> the discussion as I have followed it has been more to do with adding new
> blocks than it has been to allowing localized extensions to already
> defined blocks.

---

From: "Winterbottom, James" <[email-masked]>
Date: Wed, 1 May 2013 07:59:35 +0800

That is true Keith, but I can also do a VoIP emergency call using an OTT provider.
In this latter case my provider is only providing a packet data service of UMTS.

Cheers
James

-----Original Message-----
From: DRAGE, Keith (Keith) [mailto:[email-masked]] 
Sent: Wednesday, 1 May 2013 9:43 AM
To: Winterbottom, James; Brian Rosen; Hannes Tschofenig
Cc: [email-masked]
Subject: RE: [Ecrit] draft-ietf-ecrit-additional-data-07

Keith

> From: [email-masked] [mailto:[email-masked]] On Behalf 
> Of Winterbottom, James
> What I want/need the distinction between is a packet service and a 
> circuit service both of which can run on the same kind of "physical" 
> access. My 3G UMTS-based phone can operate in circuit-switched mode 
> for calls or in
> What I tried to provide was a way to represent this, I am open to 
> other representations providing they don't ram them all into the same 
> enumerated type.
> 
> Cheers
> James
> 
> 
> 
> Vonage, AIM, Google Talk, those are the high level services, and none 
> of them are "packet data".
> 
> Brian
> On Apr 29, 2013, at 5:22 PM, Hannes Tschofenig 
> <[email-masked]>
> wrote:
> 
> > Hi James,
> >
> document but the term doesn't seem to be obviously defined in the 
> document, nor is there is a reference to an external definition. To 
> add to this, Service Provider is a defined type in section 14.1.2, but 
> used more generally throughout the rest of the document. This needs a clarification.
> >
> this because it bundles access technologies and telephone service 
> type, though I suspect that it doesn't mean to, but in so doing it 
> left me quite confused and when I tried to describe a DOCSIS, Fibre or 
> DSL service I couldn't.  Here is a proposal to address the current 
> issues I see with this section:
> have what is currently under the "Wireless Telephone System" field and 
> I would add:
> >> a.      Twisted pair
> >> b.      Coax
> >> c.      Fibre
> conventional telephony providers which I didn't think was the only aim 
> of the document.
> >>
> > I passed this question forward to the NENA additional data group and 
> > to
> the EENA NG 112 group.
> >
> >>
> <SvcMobility> value, yet section 6.4 requires the <SvcMobility> 
> element to be included in the <emergencyCall.SvcInfo> element. I think 
> that it needs to include a value of unknown in the <SvcMobility> register.
> >
> > With the added extension point there may be more elements in there 
> > in
> the future.
> >
> on the list over the last few days might suggest that this was 
> deliberate, the discussion as I have followed it has been more to do 
> with adding new blocks than it has been to allowing localized 
> extensions to already defined blocks.