catarrh/pysim
1
0
Fork 0
forked from public/pysim
Code Pull Requests Activity
Files
ec712abd010779a5ce678b3d51c4e3f3de173355
pysim/d9ef1d314b3bebcc125ea394493a9a725c405a46
Gerrit User 1000028 1c613ca6cf Update patch set 2 
Patch Set 2:

(10 comments)

Patch-set: 2
2026-03-02 12:49:28 +00:00

462 lines
14 KiB
Plaintext
Raw Blame History

{
"comments": [
{
"unresolved": true,
"key": {
"uuid": "6f384f16_3412eeb9",
"filename": "docs/smpp-ota-tool.rst",
"patchSetId": 1
},
"lineNbr": 5,
"author": {
"id": 1000004
},
"writtenOn": "2026-02-27T13:04:29Z",
"side": 1,
"message": "an eUICC must not be a card, in fact most often it is not. I would just write \"of SIM/USIM/UICC/eUICC.\" or something like that.",
"range": {
"startLine": 5,
"startChar": 95,
"endLine": 5,
"endChar": 100
},
"revId": "d9ef1d314b3bebcc125ea394493a9a725c405a46",
"serverId": "035e6965-6537-41bd-912c-053f3cf69326"
},
{
"unresolved": false,
"key": {
"uuid": "79856fe5_73b4eaf0",
"filename": "docs/smpp-ota-tool.rst",
"patchSetId": 1
},
"lineNbr": 5,
"author": {
"id": 1000028
},
"writtenOn": "2026-03-02T12:49:28Z",
"side": 1,
"message": "I think SIM/UICC/eUICC should cover all variations. (As far as I know classic SIMs were already able to receive OTA-SMS messages)",
"parentUuid": "6f384f16_3412eeb9",
"range": {
"startLine": 5,
"startChar": 95,
"endLine": 5,
"endChar": 100
},
"revId": "d9ef1d314b3bebcc125ea394493a9a725c405a46",
"serverId": "035e6965-6537-41bd-912c-053f3cf69326"
},
{
"unresolved": true,
"key": {
"uuid": "a1dca5bb_cf9dcc7e",
"filename": "docs/smpp-ota-tool.rst",
"patchSetId": 1
},
"lineNbr": 7,
"author": {
"id": 1000004
},
"writtenOn": "2026-02-27T13:04:29Z",
"side": 1,
"message": "\"... SMPP server (such as a production SMSC of a live cellular network) as well.\"\n\nI think it makes sense to clarify that one can use this in a production setup if one is an operator and has SMPP access to ones own SMSC.",
"range": {
"startLine": 6,
"startChar": 111,
"endLine": 7,
"endChar": 6
},
"revId": "d9ef1d314b3bebcc125ea394493a9a725c405a46",
"serverId": "035e6965-6537-41bd-912c-053f3cf69326"
},
{
"unresolved": false,
"key": {
"uuid": "495d3de6_6fa25324",
"filename": "docs/smpp-ota-tool.rst",
"patchSetId": 1
},
"lineNbr": 7,
"author": {
"id": 1000028
},
"writtenOn": "2026-03-02T12:49:28Z",
"side": 1,
"message": "Done",
"parentUuid": "a1dca5bb_cf9dcc7e",
"range": {
"startLine": 6,
"startChar": 111,
"endLine": 7,
"endChar": 6
},
"revId": "d9ef1d314b3bebcc125ea394493a9a725c405a46",
"serverId": "035e6965-6537-41bd-912c-053f3cf69326"
},
{
"unresolved": true,
"key": {
"uuid": "a433b6d8_ae166f51",
"filename": "docs/smpp-ota-tool.rst",
"patchSetId": 1
},
"lineNbr": 17,
"author": {
"id": 1000004
},
"writtenOn": "2026-02-27T13:04:29Z",
"side": 1,
"message": "it\u0027s not \"a set\" but \"sets of keys\".. Somehow the paragraph doesn\u0027t really make it clear that the SCP80 keys must be used. You just say that the SCP80 protocol is used, and not that therem ight be different sets of keys for different SCPs and one of the SCP80 keysets must be used.",
"range": {
"startLine": 17,
"startChar": 73,
"endLine": 17,
"endChar": 77
},
"revId": "d9ef1d314b3bebcc125ea394493a9a725c405a46",
"serverId": "035e6965-6537-41bd-912c-053f3cf69326"
},
{
"unresolved": true,
"key": {
"uuid": "5a0511ef_2bd90920",
"filename": "docs/smpp-ota-tool.rst",
"patchSetId": 1
},
"lineNbr": 17,
"author": {
"id": 1000004
},
"writtenOn": "2026-02-27T13:04:29Z",
"side": 1,
"message": "we have many more instances of \"card\" in the document, it seems. Maybe add an initial paragraph at the top that whenever \"SIM\" is used, any of UICC/USIM/ISIM/eUICC/eSIM is actually meant? Or one could also do the same with the word \"card\": Define the word \"card\" in the context of this document as \"any SIM/USIM/ISIM/UICC/eUICC/eSIM whether or not it is in a physical card or solder form-factor\"?",
"range": {
"startLine": 17,
"startChar": 17,
"endLine": 17,
"endChar": 21
},
"revId": "d9ef1d314b3bebcc125ea394493a9a725c405a46",
"serverId": "035e6965-6537-41bd-912c-053f3cf69326"
},
{
"unresolved": false,
"key": {
"uuid": "54ddfa34_75b7b3f8",
"filename": "docs/smpp-ota-tool.rst",
"patchSetId": 1
},
"lineNbr": 17,
"author": {
"id": 1000028
},
"writtenOn": "2026-03-02T12:49:28Z",
"side": 1,
"message": "Done",
"parentUuid": "5a0511ef_2bd90920",
"range": {
"startLine": 17,
"startChar": 17,
"endLine": 17,
"endChar": 21
},
"revId": "d9ef1d314b3bebcc125ea394493a9a725c405a46",
"serverId": "035e6965-6537-41bd-912c-053f3cf69326"
},
{
"unresolved": false,
"key": {
"uuid": "ede38d0a_0f4b8232",
"filename": "docs/smpp-ota-tool.rst",
"patchSetId": 1
},
"lineNbr": 17,
"author": {
"id": 1000028
},
"writtenOn": "2026-03-02T12:49:28Z",
"side": 1,
"message": "Done",
"parentUuid": "a433b6d8_ae166f51",
"range": {
"startLine": 17,
"startChar": 73,
"endLine": 17,
"endChar": 77
},
"revId": "d9ef1d314b3bebcc125ea394493a9a725c405a46",
"serverId": "035e6965-6537-41bd-912c-053f3cf69326"
},
{
"unresolved": true,
"key": {
"uuid": "c23d3254_fea15b03",
"filename": "docs/smpp-ota-tool.rst",
"patchSetId": 1
},
"lineNbr": 26,
"author": {
"id": 1000004
},
"writtenOn": "2026-02-27T13:04:29Z",
"side": 1,
"message": "oh, are you sure? That means you cannot deploy new SCP80 (or other) keys via SCP80? I would have assumed that using RAM one could also issue PUT KEY and then the KIK would be used? Do you have a spec reference for your statement that it\u0027s not used?",
"range": {
"startLine": 26,
"startChar": 62,
"endLine": 26,
"endChar": 104
},
"revId": "d9ef1d314b3bebcc125ea394493a9a725c405a46",
"serverId": "035e6965-6537-41bd-912c-053f3cf69326"
},
{
"unresolved": false,
"key": {
"uuid": "c44f2edd_826ab9f7",
"filename": "docs/smpp-ota-tool.rst",
"patchSetId": 1
},
"lineNbr": 26,
"author": {
"id": 1000028
},
"writtenOn": "2026-03-02T12:49:28Z",
"side": 1,
"message": "I have asked myself the same question but I could not find any reference to KIK in ETSI TS 102 225\n\nThis lead me to the assumption that KIK is not available in SCP80. When I look at Table 1. There is only \"KIc\" and \"KID\", not \"KIK\" or anything. We also only have the sections \"Coding of KIc\" and \"Coding of KID\".\n\nBut I have had closer look at this again now: ETSI TS 102 226, section 8.2.1.5 hints towards that the KIK (DEK) is implicitly selected. KIc and KID must be the same numbers anyway (mixing keys from different keysets is forbidden, but SCP80 would technically allow it). The spec says: \"The transport security keys (i.e. KIc/KID) used to secure the Response Packet shall be the same as the ones of the\nCommand Packet containing the PUT KEY command.\", so when KIc/KID is 1, then KIK is also 1. and so on.\n\nSo, I think we should write this paragraph a bit differently...\n\n(I still have problems to understand to which layer the KIK actually belongs to. To me it seems that it is more or less something that is specific to put_key. If this is true it should not be mentioned in any of those specs and only be discussed in the global platform spec where put_key is specified.)",
"parentUuid": "c23d3254_fea15b03",
"range": {
"startLine": 26,
"startChar": 62,
"endLine": 26,
"endChar": 104
},
"revId": "d9ef1d314b3bebcc125ea394493a9a725c405a46",
"serverId": "035e6965-6537-41bd-912c-053f3cf69326"
},
{
"unresolved": true,
"key": {
"uuid": "29e48c59_b5678c82",
"filename": "docs/smpp-ota-tool.rst",
"patchSetId": 1
},
"lineNbr": 28,
"author": {
"id": 1000004
},
"writtenOn": "2026-02-27T13:04:29Z",
"side": 1,
"message": "the keyset doesn\u0027t have to be in the ISD. I think any security domain (whether issuer or supplementary) could in theory specify its own material? Might be best to just say \"security domain\" without being too specific.",
"range": {
"startLine": 28,
"startChar": 19,
"endLine": 28,
"endChar": 67
},
"revId": "d9ef1d314b3bebcc125ea394493a9a725c405a46",
"serverId": "035e6965-6537-41bd-912c-053f3cf69326"
},
{
"unresolved": false,
"key": {
"uuid": "e8a9027a_153c6f3a",
"filename": "docs/smpp-ota-tool.rst",
"patchSetId": 1
},
"lineNbr": 28,
"author": {
"id": 1000028
},
"writtenOn": "2026-03-02T12:49:28Z",
"side": 1,
"message": "Done",
"parentUuid": "29e48c59_b5678c82",
"range": {
"startLine": 28,
"startChar": 19,
"endLine": 28,
"endChar": 67
},
"revId": "d9ef1d314b3bebcc125ea394493a9a725c405a46",
"serverId": "035e6965-6537-41bd-912c-053f3cf69326"
},
{
"unresolved": true,
"key": {
"uuid": "d24b1c40_3c72e02a",
"filename": "docs/smpp-ota-tool.rst",
"patchSetId": 1
},
"lineNbr": 84,
"author": {
"id": 1000004
},
"writtenOn": "2026-02-27T13:04:29Z",
"side": 1,
"message": "might be worth using formatting instructions to use monospaced font for all APDUs or other hex-strings",
"range": {
"startLine": 84,
"startChar": 16,
"endLine": 84,
"endChar": 30
},
"revId": "d9ef1d314b3bebcc125ea394493a9a725c405a46",
"serverId": "035e6965-6537-41bd-912c-053f3cf69326"
},
{
"unresolved": false,
"key": {
"uuid": "e63b30fb_1f32f751",
"filename": "docs/smpp-ota-tool.rst",
"patchSetId": 1
},
"lineNbr": 84,
"author": {
"id": 1000028
},
"writtenOn": "2026-03-02T12:49:28Z",
"side": 1,
"message": "Done",
"parentUuid": "d24b1c40_3c72e02a",
"range": {
"startLine": 84,
"startChar": 16,
"endLine": 84,
"endChar": 30
},
"revId": "d9ef1d314b3bebcc125ea394493a9a725c405a46",
"serverId": "035e6965-6537-41bd-912c-053f3cf69326"
},
{
"unresolved": true,
"key": {
"uuid": "24338766_a56d9080",
"filename": "docs/smpp-ota-tool.rst",
"patchSetId": 1
},
"lineNbr": 86,
"author": {
"id": 1000004
},
"writtenOn": "2026-02-27T13:04:29Z",
"side": 1,
"message": "might be worth stating that he SIM RFM application is \"on the card\"",
"revId": "d9ef1d314b3bebcc125ea394493a9a725c405a46",
"serverId": "035e6965-6537-41bd-912c-053f3cf69326"
},
{
"unresolved": false,
"key": {
"uuid": "c4c34553_7cc37059",
"filename": "docs/smpp-ota-tool.rst",
"patchSetId": 1
},
"lineNbr": 86,
"author": {
"id": 1000028
},
"writtenOn": "2026-03-02T12:49:28Z",
"side": 1,
"message": "Done",
"parentUuid": "24338766_a56d9080",
"revId": "d9ef1d314b3bebcc125ea394493a9a725c405a46",
"serverId": "035e6965-6537-41bd-912c-053f3cf69326"
},
{
"unresolved": true,
"key": {
"uuid": "72d2a4ae_e9bf2c30",
"filename": "docs/smpp-ota-tool.rst",
"patchSetId": 1
},
"lineNbr": 119,
"author": {
"id": 1000004
},
"writtenOn": "2026-02-27T13:04:29Z",
"side": 1,
"message": "it might be worth mentioning at some earlier point that the MSL of the card may be different for different card types/profiles, and that cards beyond lab/experimentation use should ideally have a MSL that makes the use of the counter mandatory. It\u0027s just the sysmoISIM-SJS1/SJA2/SJA5 that do not have a MSL requiring a counter as that makes it easier for lab/research type use.",
"range": {
"startLine": 115,
"startChar": 1,
"endLine": 119,
"endChar": 93
},
"revId": "d9ef1d314b3bebcc125ea394493a9a725c405a46",
"serverId": "035e6965-6537-41bd-912c-053f3cf69326"
},
{
"unresolved": false,
"key": {
"uuid": "5be08627_e556b4b9",
"filename": "docs/smpp-ota-tool.rst",
"patchSetId": 1
},
"lineNbr": 119,
"author": {
"id": 1000028
},
"writtenOn": "2026-03-02T12:49:28Z",
"side": 1,
"message": "Done",
"parentUuid": "72d2a4ae_e9bf2c30",
"range": {
"startLine": 115,
"startChar": 1,
"endLine": 119,
"endChar": 93
},
"revId": "d9ef1d314b3bebcc125ea394493a9a725c405a46",
"serverId": "035e6965-6537-41bd-912c-053f3cf69326"
},
{
"unresolved": true,
"key": {
"uuid": "7d9b144f_664ade33",
"filename": "docs/smpp-ota-tool.rst",
"patchSetId": 1
},
"lineNbr": 162,
"author": {
"id": 1000004
},
"writtenOn": "2026-02-27T13:04:29Z",
"side": 1,
"message": "\"... it will not wrap on overflow ...",
"range": {
"startLine": 162,
"startChar": 57,
"endLine": 162,
"endChar": 64
},
"revId": "d9ef1d314b3bebcc125ea394493a9a725c405a46",
"serverId": "035e6965-6537-41bd-912c-053f3cf69326"
},
{
"unresolved": false,
"key": {
"uuid": "f516e49f_69754f5e",
"filename": "docs/smpp-ota-tool.rst",
"patchSetId": 1
},
"lineNbr": 162,
"author": {
"id": 1000028
},
"writtenOn": "2026-03-02T12:49:28Z",
"side": 1,
"message": "Done",
"parentUuid": "7d9b144f_664ade33",
"range": {
"startLine": 162,
"startChar": 57,
"endLine": 162,
"endChar": 64
},
"revId": "d9ef1d314b3bebcc125ea394493a9a725c405a46",
"serverId": "035e6965-6537-41bd-912c-053f3cf69326"
}
]
}
View Git Blame Copy Permalink