Re: [3gpp-ietf-coord] [Last-Call] Review of draft-ietf-lpwan-schc-over-nbiot-13

[Ivo Sedlacek <[e-mail]>]

Hello,

I have reviewed https://datatracker.ietf.org/doc/html/draft-ietf-lpwan-schc-over-nbiot-14

All my comments raised before except COMMENT-4 are addressed OK, and I have no new comments.

For COMMENT-4:


section 4 now states:

------------------------

The Open Mobile Alliance (OMA) [OMA0116] and the One Machine to Machine (OneM2M) [TR-0024] define the northbound APIs [TS33122].

------------------------



The relationship between (a) [OMA0116] and [TR-0024] and (b) [TS33122] is not clear.



Name of 3GPP TS 33.122 (lastest version at https://www.3gpp.org/ftp/Specs/archive/33_series/33.122/33122-h00.zip) is "Security aspects of Common API Framework (CAPIF) for 3GPP northbound APIs".

Scope of 3GPP TS 33.122 is "The present document specifies the security architecture i.e., the security features and the security mechanisms for the common API framework (CAPIF) as per the architecture and procedures defined in 3GPP TS 23.222 [3].".



We could also mention 3GPP TS 23.222 (latest version at https://www.3gpp.org/ftp/Specs/archive/23_series/23.222/23222-h70.zip).

Name of 3GPP TS 23.122 is "Common API Framework for 3GPP Northbound APIs".

Scope of 3GPP TS 33.122 is "The present document specifies the architecture, procedures and information flows necessary for the CAPIF. The aspects of this specification include identifying architecture requirements for the CAPIF (e.g. registration, discovery, identity management) that are applicable to any service APIs when used by northbound entities, as well as any interactions between the CAPIF and the service APIs themselves. The common API framework applies to both EPS and 5GS, and is independent of the underlying 3GPP access (e.g. E-UTRA, NR).".



Proposal-alternative-1:

------------------------

The Open Mobile Alliance (OMA) [OMA0116] and the One Machine to Machine (OneM2M) [TR-0024] define the northbound APIs.

------------------------



Proposal-alternative-2:

------------------------

The Open Mobile Alliance (OMA) [OMA0116] and the One Machine to Machine (OneM2M) [TR-0024] define the northbound APIs. [TS33122] defines security aspects of common API framework for 3GPP northbound APIs.

------------------------



Proposal-alternative-3:

------------------------

The Open Mobile Alliance (OMA) [OMA0116] and the One Machine to Machine (OneM2M) [TR-0024] define the northbound APIs. [TS23222] defines architecture for the common API framework for 3GPP northbound APIs and [TS33122] defines security aspects for common API framework for 3GPP northbound APIs.

------------------------

Kind regards

Ivo

From: Ivo Sedlacek
Sent: úterý 13. prosince 2022 14:15
To: Eric Vyncke (evyncke) <evyncke=[e-mail]>; Ana Minaburo <[e-mail]>
Cc: [e-mail]; Lars Eggert <[e-mail]>; [e-mail]; Edgar Ramos <[e-mail]>; Gonzalo Camarillo <[e-mail]>; [e-mail]
Subject: RE: [Last-Call] Review of draft-ietf-lpwan-schc-over-nbiot-13

Hello,

I got the draft but I have not checked it yet.

I will do so tomorrow (busy today with other issues).

Kind regards

Ivo

From: Eric Vyncke (evyncke) <evyncke=[e-mail]<mailto:evyncke=[e-mail]>>
Sent: úterý 13. prosince 2022 14:09
To: Ana Minaburo <[e-mail]<mailto:[e-mail]>>; Ivo Sedlacek <[e-mail]<mailto:[e-mail]>>
Cc: [e-mail]<mailto:[e-mail]>; Lars Eggert <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>; Edgar Ramos <[e-mail]<mailto:[e-mail]>>; Gonzalo Camarillo <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>
Subject: Re: [Last-Call] Review of draft-ietf-lpwan-schc-over-nbiot-13

Thank you, Ana, for posting a revised IETF draft addressing all Ivo concerns (I have checked that all of them are addressed).

Lars,

Ivo's review is the only review (and a good one) that LP-WAN has received after our liaison statement of the 19th of October 2022 [LS]. As discussed during the 3GPP-IETF meeting at IETF-115 in London about the informational/standards split of the I-D, and as this work has been done as a follow-up action on the 2016 liaison statement from 3GPP [LS2], would you mind reviewing your DISCUSS ballot with the revision -24 ?

Thanks a lot, in advance

Regards

-éric

[LS] https://datatracker.ietf.org/liaison/1796/
[LS2] https://datatracker.ietf.org/liaison/1480/


From: Ana Minaburo <[e-mail]<mailto:[e-mail]>>
Date: Tuesday, 13 December 2022 at 10:34
To: Ivo Sedlacek <ivo.sedlacek=[e-mail]<mailto:ivo.sedlacek=[e-mail]>>
Cc: "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>, Lars Eggert <[e-mail]<mailto:[e-mail]>>, "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>, Edgar Ramos <[e-mail]<mailto:[e-mail]>>, Gonzalo Camarillo <[e-mail]<mailto:[e-mail]>>, "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>, Eric Vyncke <[e-mail]<mailto:[e-mail]>>
Subject: Re: [Last-Call] Review of draft-ietf-lpwan-schc-over-nbiot-13

Dear Ivo,

Thank you very much for your valuable inputs. Please find below our comments
A new version of the draft will be published with your comments.

Ana

On Tue, Dec 6, 2022 at 12:51 PM Eric Vyncke (evyncke) <[e-mail]<mailto:[e-mail]>> wrote:
Thank you, Ivo, for the clarification. We will assume then that the review was individual and will not enter it as a liaison statement.

Regards

-éric

From: Ivo Sedlacek <ivo.sedlacek=[e-mail]<mailto:[e-mail]>>
Date: Tuesday, 6 December 2022 at 10:16
To: Eric Vyncke <[e-mail]<mailto:[e-mail]>>, "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>, "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>
Cc: lp-wan <[e-mail]<mailto:[e-mail]>>, Lars Eggert <[e-mail]<mailto:[e-mail]>>, "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>, Edgar Ramos <[e-mail]<mailto:[e-mail]>>, Gonzalo Camarillo <[e-mail]<mailto:[e-mail]>>
Subject: RE: [Last-Call] Review of draft-ietf-lpwan-schc-over-nbiot-13

Hello,

thank you for your mail.

I am happy to take part in discussion with authors on my comments, and review update draft, if and when produced.

> May the IETF assume that your email is the 3GPP answer to the liaison statement referred in your email ? If so, then I will enter your email reply into the IETF list of liaison statements https://datatracker.ietf.org/liaison/

The review was provided on my own behalf. I do not speak on behalf of entire 3GPP.

Kind regards

Ivo

From: Eric Vyncke (evyncke) <evyncke=[e-mail]<mailto:[e-mail]>>
Sent: pondělí 5. prosince 2022 17:18
To: Ivo Sedlacek <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>
Cc: lp-wan <[e-mail]<mailto:[e-mail]>>; Lars Eggert <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>; Edgar Ramos <[e-mail]<mailto:[e-mail]>>; Gonzalo Camarillo <[e-mail]<mailto:[e-mail]>>
Subject: Re: [Last-Call] Review of draft-ietf-lpwan-schc-over-nbiot-13

[Adding LP-WAN WG mailing list as well as the 3GPP-IETF coordination list]

Ivo,

Thank you very much for your valuable review: I am sure that the authors will update their documents based on your detailed review and they will let you know.

May the IETF assume that your email is the 3GPP answer to the liaison statement referred in your email ? If so, then I will enter your email reply into the IETF list of liaison statements https://datatracker.ietf.org/liaison/

Once again, thank you

Regards

-éric

From: last-call <[e-mail]<mailto:[e-mail]>> on behalf of Ivo Sedlacek <ivo.sedlacek=[e-mail]<mailto:ivo.sedlacek=[e-mail]>>
Date: Monday, 5 December 2022 at 16:41
To: "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>
Subject: [Last-Call] Review of draft-ietf-lpwan-schc-over-nbiot-13

Hello,

3GPP TSG CT WG 1 received an liaison statement (LS) https://3gpp.org/ftp/tsg_ct/WG1_mm-cc-sm_ex-CN1/TSGC1_138e/Docs/C1-226012.zip<https://protect2.fireeye.com/v1/url?k=31323334-501d5122-313273af-454445555731-f4faa101d0a8634e&q=1&e=95d62817-daf6-450a-afde-855d59d66acc&u=https%3A%2F%2F3gpp.org%2Fftp%2Ftsg_ct%2FWG1_mm-cc-sm_ex-CN1%2FTSGC1_138e%2FDocs%2FC1-226012.zip> from IETF LPWAN working group, requesting comments on draft-ietf-lpwan-schc-over-nbiot.

I am working in 3GPP CT1 on behalf of Ericsson.

My comments to https://www.ietf.org/archive/id/draft-ietf-lpwan-schc-over-nbiot-13.txt are below.


COMMENT-1:

section 3 "   *  HSS.  Home Subscriber Server.  It is a database that performs

      mobility management.
"  -> HSS contains subscription data for users. While HSS contains in the subscription data some information needed for mobility management, the mobility management itself is performed by MME based on subscription data from the HSS.

Proposal:
-------------

*  HSS.  Home Subscriber Server.  It is a database that contains users' subscription data, including data needed for mobility management.
-------------

[Ana] Done. I've changed it.


COMMENT-2:

section 3 "   *  NGW-PGW.  Network Gateway - Packet Data Node Gateway.  An

      interface between the internal with the external network.

" -> P-GW is abbreviation for "PDN Gateway" (see 3GPP TS 24.301) and "PDN" is abbreviation for "Packet Data Network" (see 3GPP TR 21.905). So, text should refer to "Packet Data Network Gateway" (rather than Packet Data Node Gateway"). This comment also applies other places in the document.


Proposal:
-------------

   *  NGW-PGW.  Network Gateway - Packet Data Network Gateway.  An interface between the internal with the external network.
-------------
and "Packet Data Network Gateway" should be used instead of "Packet Data Node Gateway" anywhere in the draft.
[Ana] Done.



COMMENT-3:

section 4 "   Figure 1 shows this architecture, where the Network Gateway Cellular
   Internet of Things Serving Gateway Node (NGW-CSGN) optimizes co-
   locating entities in different paths.  For example, a Dev-UE using
   the path formed by the Network Gateway Mobility Management Entity
   (NGW-MME), the NGW-CSGW, and Network Gateway Packet Data Node Gateway
   (NGW-PGW) may get a limited bandwidth transmission from a few bytes/s
   to one thousand bytes/s only.

" - figure 1 does not show NGW-CSGN. Figure 1 only shows the Dev-UEs, RGW-eNB, NGW-MME, NGW-CSGW, HSS, NGW-SCEF, NGW-PGW, and application server.

                   If the intention of NGW-CSGN is to include all those entities, then it should be stated - in section 3, section 4 or both.

                   If the intention of NGW-CSGN is to include some of those entities (e.g. all except Dev-UEs and AS), then it should be stated too - in section 3, section 4 or both.

[Ana] Neither one nor the other, the only intention was to simplify the architecture to give the most important elements. I've changed fig1 and I added the NGW-CSGN which involves the NGW-MME and NGW-CSGW



COMMENT-4:

section 4 "The Open Mobile Alliance (OMA)

   [TS23222] and the One Machine to Machine (OneM2M) [TR-0024] define

   the northbound APIs [TR33203]."

- 3GPP TS 23.222 is a 3GPP document (rather than OMA document) so the reference name "[TS23222]" seems misleading.

- 3GPP TS 33.203 is a TS rather than TR. Moreover, 3GPP TS 33.203 is a document for IP Multimedia subsystem and its relationship to LPWAN is not clear.



Proposal:

- for TS 23.222 - either replace it with OMA documents defining northbound APIs, or refer to 3GPP for TS 23.222.

[Ana] As I used the OMA document, I will put OMA's Reference.


- for TS 33.203 - replace with correct TS number for northbound APIs. Likely TS 33.122 is meant.

[Ana] I've  changed it.


COMMENT-5:

section 5 "   3GPP standardizes NB-IoT and, in general, the cellular technologies

   interfaces and functions.  Therefore, the introduction of SCHC

   entities to Dev-UE, RGW-eNB, and NGW-CSGN needs to be specified in

   the NB-IoT standard, which implies that the standard specifying SCHC

   support would not be backward compatible.

" -> statement "the standard specifying SCHC support would not be backward compatible" is not necessarily true. It depends on method selected for introduction of SCHC - e.g. if support of SCHC is negotiated before SCHC usage, introduction of SCHC can be backward  compatible.



Proposal: remove text ", which implies that the standard specifying SCHC

   support would not be backward compatible"
[Ana] Done



COMMENT-6:

section 5 "The radio network transmits the

   packets as non-IP traffic using IP tunneling or SCEF services.

" - it is not clear what is meant by "radio network".

If "radio network" means RGW-eNB (acting towards NGW-MME or NGW-CSGW), then this is not correct as RGW-eNB communicates with NGW-MME or NGW-CSGW (and not SCEF).

If "radio network" means entire 3GPP network (except application server) acting towards application server, then this would be correct.




Proposal: "NGW-PGW or NGW-SCEF transmit the packets which are non-IP traffic, using IP tunneling or API calls."

[Ana] Done



COMMENT-7:

section 5.1.1 "The packets can be delivered using IP-tunnels to the 3GPP network or

   NGW-SCEF functions (i.e., API calls).

" - the above is not very clear:

- if this refers to packet exchange between NGW-PGW and Application Server or NGW-SCEF and Application Server, fine.

- If this refers to packets exchanged between Dev-UE and Application Server, this is not completely correct - non-IP data PDU is transported between Dev-UE and RGW-eNB without IP tunnel.



Proposal: "The packets can be delivered between the NGW-PGW and the Application Server or between the NGW-SCEF and the Application Server, using IP-tunnels or API calls.".
[Ana] Done




COMMENT-8:

section 5.1.1.2 "A global service assigns a QoS to the packets depending on the

   billing.

" - while this is possible, QoS can be assigned due to other reasons too.



Proposal: "A global service assigns a QoS to the packets e.g. depending on the billing."
[Ana] Done



COMMENT-9:

section 5.2.2 "No-Access Stratum (NAS)" - "NAS" stands for "Non-Access Stratum" (see 3GPP TR 21.905). This comment also applies to other places in the document.



Proposal: "replace "No-Access Stratum (NAS)" with "Non-Access Stratum (NAS)" anywhere in the draft
[Ana] Done



COMMENT-10:.

- section 5.2.2.1 "S1-lite" - "S1-lite" does not seem to be defined in any of TS 23.401. TS 36.300 or TS 36.413. Please add a reference for 3GPP specification or use S1.
[Ana] I kept S1



COMMENT-11:

appendix B "NAS packets are encapsulated within an RRC (Radio

   Resource Control) TGPP36331 message.

" -> not clear what "TGPP36331" is. Likely, this should be a reference to 3GPP TS 36.331.
[Ana] Good Catch! I've put the Reference



Proposal: "NAS packets are encapsulated within an RRC (Radio Resource Control) (see [TGPP36331]) message." and add a reference to TS 36.331 in section 9.

[Ana] Done



Kind regards



Ivo