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

From: "Winterbottom, James" <[email-masked]>
Date: Mon, 18 Mar 2013 11:41:28 +0800

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.

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.

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.

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

Cheers
James

---

From: "Rosen, Brian" <[email-masked]>
Date: Mon, 18 Mar 2013 12:51:09 +0000

Thanks for these comments, and they were just in time, as I was about to release a new version addressing your prior concerns.  Unless anyone objects, I'll make these changes.

Brian

On Mar 17, 2013, at 11:41 PM, "Winterbottom, James" <[email-masked]<mailto:[email-masked]>> wrote:

Hi Authors,

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.

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.

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.

NITS
=====

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

---

From: "Winterbottom, James" <[email-masked]>
Date: Tue, 19 Mar 2013 06:29:57 +0800

Hi Brian,

Thanks for the fast response.
one more quick thing in section 6.4, the schema for the emergencyCall.SvcInfo. There is an element in the sequence called <Link> but it isn't clear what one would use this for since it isn't defined like the other elements are.

Also, increasingly we are seeing single number services, that is my mobile and home phone can have the same number. If this data is statically maintained against my TN then I might want to have multiple emergencyCall.SvcInfo blocks. Is this allowed?

Cheers
James

From: Rosen, Brian [mailto:[email-masked]]
Sent: Monday, 18 March 2013 11:51 PM
To: Winterbottom, James
Cc: [email-masked]
Subject: Re: [Ecrit] draft-ietf-ecrit-additional-data-07

Brian

Hi Authors,

Comments:
=================

NITS
=====

Cheers
James