Re: [auth48] [AD] Re: AUTH48: RFC-to-be 9254 <draft-ietf-core-yang-cbor-20> for your review

[Michel Veillette <[e-mail]>]

As a reminder, the term "collection", used to be in the section 4.2 title and text, see https://datatracker.ietf.org/doc/html/draft-ietf-core-yang-cbor-07#section-4.2.

4.2.   The 'container' and other collections

   Collections such as containers, list instances, notification
   contents, rpc inputs, rpc outputs, action inputs and action outputs
   MUST be encoded using a CBOR map data item (major type 5).



-----Original Message-----
From: Carsten Bormann <[e-mail]> 
Sent: 11 juillet 2022 09:55
To: Francesca Palombini <[e-mail]>
Cc: Alanna Paloma <[e-mail]>; [e-mail]; [e-mail]; [e-mail]; Marco Tiloca <[e-mail]>; [e-mail]; [e-mail]; [e-mail]; Michael Richardson <[e-mail]>; Michel Veillette <[e-mail]>
Subject: Re: [auth48] [AD] Re: AUTH48: RFC-to-be 9254 <draft-ietf-core-yang-cbor-20> for your review

External Email: Please use caution when opening links and attachments / Courriel externe: Soyez prudent avec les liens et documents joints

Hi Francesca,

> Carsten, authors: question about the changes in section 4.5. You say:
>
> >(3)
> >We found the bullet list at the start of 4.5 confusing and hard to fix.

. and I should have said what would need fixing if we insist to repeat statements from other sections.  But that is a lot of fixing, which is why we proposed the approach of referring to 4.2.

> >We decided that the best fix is to simply not to repeat the material 
> >that is already in 4.2, but to instead point to that.
> >Removing the text that is trying to be redundant actually is an 
> >editorial change, in lieu of making a number of risky editorial 
> >changes to the items in the bullet list.
> >
> >This simplification is laid out in:
> >
> >https://can01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgit
> >hub.com%2Fcore-wg%2Fyang-cbor%2Fblob%2Fauth48%2Fauth48%2Frfc9254.xml&
> >amp;data=05%7C01%7CMichel.Veillette%40trilliant.com%7Ca926d83aba07458
> >5913d08da6344faa3%7C4f6fbd130dfb415085c3d43260c04309%7C0%7C0%7C637931
> >446298971425%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2lu
> >MzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&amp;sdata=mZbOACqi
> >UzNVbEZusjSwxFlrIAt02gxoMmT6d9srZSY%3D&amp;reserved=0
> >specifically:
> >https://can01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgit
> >hub.com%2Fcore-wg%2Fyang-cbor%2Fcommit%2Fccdc64f&amp;data=05%7C01%7CM
> >ichel.Veillette%40trilliant.com%7Ca926d83aba074585913d08da6344faa3%7C
> >4f6fbd130dfb415085c3d43260c04309%7C0%7C0%7C637931446298971425%7CUnkno
> >wn%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwi
> >LCJXVCI6Mn0%3D%7C3000%7C%7C%7C&amp;sdata=vbBEmuFWKLBVGr5%2F1aa8DwNks4
> >o7S2NdYjtBIazKbOk%3D&amp;reserved=0
>
> However it seems to me with this simplification there are actual changes to the requirements:

Let my try to explain how we got into this situation.

anydata is a murky part of RFC 7950.  It generally gets reviewers into "shrug-mode" because it is so unclear in the original YANG RFC.

RFC 7951, YANG-JSON, resorted to this approach:

   The requirement that anydata content can be
   modeled by YANG implies the following rules for the JSON text inside
   the object:

. and follows this with an incomplete and somewhat irrelevant list of implications.  It is not quite clear how normative this list is, as he way it is introduced qualifies it as descriptive, not prescriptive.
But what is really needed is the requirement that "anydata content can be modeled by YANG".

Unfortunately, we followed the approach of RFC 7951, which resulted in the even more incomplete and misleading list that is now in YANG-CBOR.

When developing YANG-CBOR, we concentrated the scattered information needed how to do this in 4.2, which is essentially the blueprint for all container-like information (including Section 5).
We neglected to make use of that in the introduction to 4.5; this is unfortunate also because anydata is being used more now (as can be seen in the examples).

> one obvious one is that where before the text said "keys MUST be set to valid deltas or names" now by pointing at 4.2 absolute SIDs (tagged) are also valid keys.

Note that 4.5.1 then goes on to show an example that actually *uses* absolute SIDs.

anydata being aligned with the rest of the document was always the intention, but (maybe because of the "icky" reflex to anydata) we didn't follow through with fixing that bullet list.

> Additionally, there are no more requirements on CBOR arrays, that I can tell.

The bullet list really is the wrong way around, because it should be discussing how YANG data are represented in CBOR, and not how specific types CBOR data have requirements following from the YANG they represent.  As the existing second bullet entry tries to say, CBOR arrays are used for lists and leaf-lists, and the rules for those (4.3, 4.4) apply.  This is of course true for arrays occurring in any other usage of 4.2 (container, list item, .).

> Also, I see the use of the text "based on the encoding rules of a collection, as defined in section 4.2" but specifically the term collection is not used in 4.2 (by the way this also applies for the second occurrence of collection in 4.4), so I have a hard time mapping that requirement on CBOR map values to section 4.2. Could you clarify?

4.2 starts with:

   Instances of containers, YANG data structures, notification contents,
   RPC inputs, RPC outputs, action inputs, and action outputs MUST be
   encoded using a CBOR map data item (major type 5).  The same encoding
   is also used for the list entries in a list (Section 4.4).  [.]

Apparently, we meant to use the term "collection" to refer to these "container-like" items, but never introduced it.  The best way to handle this is probably to introduce "container-like item" as a term, give it the meaning to refer to the items discussed in 4.2, and use that term in 4.4 and 4.5.

So I would propose going ahead with fixing the dangling reference to "collection" this way.  I didn't even notice that ccdc64f could be perceived as more than an editorial change, because it is so obvious (to me) that this was intended.
But how to handle this (from my point of view) clarification is for you to decide.

Grüße, Carsten

>
> Thanks,
> Francesca
>
> From: Alanna Paloma <[e-mail]>
> Date: Friday, 8 July 2022 at 21:33
> To: Michel Veillette <[e-mail]>, Carsten Bormann 
> <[e-mail]>, Francesca Palombini <[e-mail]>
> Cc: [e-mail] <[e-mail]>, 
> [e-mail] <[e-mail]>, [e-mail] 
> <[e-mail]>, Marco Tiloca <[e-mail]>, 
> [e-mail] <[e-mail]>, 
> [e-mail] <[e-mail]>, [e-mail] 
> <[e-mail]>, Michael Richardson <[e-mail]>
> Subject: [AD] Re: AUTH48: RFC-to-be 9254 
> <draft-ietf-core-yang-cbor-20> for your review
>
> Michel, Carsten, and *Francesca (AD),
>
> Thank you for your replies. We have updated the files accordingly and noted Michel's approval on the AUTH48 status page.
>
> *Francesca (AD) - In addition to the added text in Section 2, please review and approve of the changes to the text in Section 4.5 and the addition of  "(major type 4)" in Section 6.7. These changes can be seen in the diff file below:
> https://can01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.
> rfc-editor.org%2Fauthors%2Frfc9254-ad-diff.html&amp;data=05%7C01%7CMic
> hel.Veillette%40trilliant.com%7Ca926d83aba074585913d08da6344faa3%7C4f6
> fbd130dfb415085c3d43260c04309%7C0%7C0%7C637931446298971425%7CUnknown%7
> CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXV
> CI6Mn0%3D%7C3000%7C%7C%7C&amp;sdata=mvuP1PgUa5HdpwsQ1J4hhSkw9uyL7QNZH0
> snLe7gOgg%3D&amp;reserved=0
>
> The files have been posted here (please refresh):
> https://can01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.
> rfc-editor.org%2Fauthors%2Frfc9254.txt&amp;data=05%7C01%7CMichel.Veill
> ette%40trilliant.com%7Ca926d83aba074585913d08da6344faa3%7C4f6fbd130dfb
> 415085c3d43260c04309%7C0%7C0%7C637931446298971425%7CUnknown%7CTWFpbGZs
> b3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D
> %7C3000%7C%7C%7C&amp;sdata=O61Cdl%2BI5vdXRRegNfYFhYLuPt20zLN4wKrkwlpav
> I8%3D&amp;reserved=0
> https://can01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.
> rfc-editor.org%2Fauthors%2Frfc9254.pdf&amp;data=05%7C01%7CMichel.Veill
> ette%40trilliant.com%7Ca926d83aba074585913d08da6344faa3%7C4f6fbd130dfb
> 415085c3d43260c04309%7C0%7C0%7C637931446299127670%7CUnknown%7CTWFpbGZs
> b3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D
> %7C3000%7C%7C%7C&amp;sdata=2DmB7KRCjisLmshomENZwHgVtcBwB6Tw6JL4d%2FbQi
> a8%3D&amp;reserved=0
> https://can01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.
> rfc-editor.org%2Fauthors%2Frfc9254.html&amp;data=05%7C01%7CMichel.Veil
> lette%40trilliant.com%7Ca926d83aba074585913d08da6344faa3%7C4f6fbd130df
> b415085c3d43260c04309%7C0%7C0%7C637931446299127670%7CUnknown%7CTWFpbGZ
> sb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3
> D%7C3000%7C%7C%7C&amp;sdata=1qOfi0ph8FNjLTQht83%2FZn1K22YIgtjeIGDPUrd%
> 2FoAE%3D&amp;reserved=0
> https://can01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.
> rfc-editor.org%2Fauthors%2Frfc9254.xml&amp;data=05%7C01%7CMichel.Veill
> ette%40trilliant.com%7Ca926d83aba074585913d08da6344faa3%7C4f6fbd130dfb
> 415085c3d43260c04309%7C0%7C0%7C637931446299127670%7CUnknown%7CTWFpbGZs
> b3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D
> %7C3000%7C%7C%7C&amp;sdata=2QenlqVdoNpEoezmtcWkws9733BK8lgIBYPVjncGWxs
> %3D&amp;reserved=0
>
> The relevant diff files are posted here:
> https://can01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.
> rfc-editor.org%2Fauthors%2Frfc9254-diff.html&amp;data=05%7C01%7CMichel
> .Veillette%40trilliant.com%7Ca926d83aba074585913d08da6344faa3%7C4f6fbd
> 130dfb415085c3d43260c04309%7C0%7C0%7C637931446299127670%7CUnknown%7CTW
> FpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6
> Mn0%3D%7C3000%7C%7C%7C&amp;sdata=LtQ%2B85ZoStnlOzfj1KL5M0pYciCfbVY3bt4
> ezbXv%2BZM%3D&amp;reserved=0 (comprehensive diff)
> https://can01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.
> rfc-editor.org%2Fauthors%2Frfc9254-auth48diff.html&amp;data=05%7C01%7C
> Michel.Veillette%40trilliant.com%7Ca926d83aba074585913d08da6344faa3%7C
> 4f6fbd130dfb415085c3d43260c04309%7C0%7C0%7C637931446299127670%7CUnknow
> n%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLC
> JXVCI6Mn0%3D%7C3000%7C%7C%7C&amp;sdata=VQJPO2FDqHHwrMqJqkr3Qc7Dowy1V5d
> zRXUxS04Aom8%3D&amp;reserved=0 (all AUTH48 changes)
> https://can01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.
> rfc-editor.org%2Fauthors%2Frfc9254-lastdiff.html&amp;data=05%7C01%7CMi
> chel.Veillette%40trilliant.com%7Ca926d83aba074585913d08da6344faa3%7C4f
> 6fbd130dfb415085c3d43260c04309%7C0%7C0%7C637931446299127670%7CUnknown%
> 7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJX
> VCI6Mn0%3D%7C3000%7C%7C%7C&amp;sdata=1dqY2wZg%2FERjl%2BwNjUQ0gqql1Zenj
> RZWNi8QluYUaYM%3D&amp;reserved=0 (htmlwdiff diff between last version 
> and this)
> https://can01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.
> rfc-editor.org%2Fauthors%2Frfc9254-lastrfcdiff.html&amp;data=05%7C01%7
> CMichel.Veillette%40trilliant.com%7Ca926d83aba074585913d08da6344faa3%7
> C4f6fbd130dfb415085c3d43260c04309%7C0%7C0%7C637931446299127670%7CUnkno
> wn%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiL
> CJXVCI6Mn0%3D%7C3000%7C%7C%7C&amp;sdata=reZKh94mPbUunPkK60Hem4oqzsqJPn
> DERkUDm9TTuUc%3D&amp;reserved=0 (rfcdiff between last version and 
> this)
>
> Please see the AUTH48 status page for this document here:
> https://can01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.
> rfc-editor.org%2Fauth48%2Frfc9254&amp;data=05%7C01%7CMichel.Veillette%
> 40trilliant.com%7Ca926d83aba074585913d08da6344faa3%7C4f6fbd130dfb41508
> 5c3d43260c04309%7C0%7C0%7C637931446299127670%7CUnknown%7CTWFpbGZsb3d8e
> yJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C30
> 00%7C%7C%7C&amp;sdata=ONUdhJQrO8gffdR2y2%2Fvdt0x5%2Ba5JNk2MeYK573q0XY%
> 3D&amp;reserved=0
>
> Thank you,
> RFC Editor/ap
>
> > On Jul 8, 2022, at 11:04 AM, Carsten Bormann <[e-mail]> wrote:
> >
> > On 2022-07-08, at 18:58, Michel Veillette <[e-mail]> wrote:
> >>
> >> Hi RFC Editor
> >>
> >> I approve the latest version of  "RFC-to-be 9254" which include the following commits:
> >> * dd233ef Mention major type of CBOR array for consistency
> >> * 07d3a4c Use consistent "Definition example adapted from"...
> >> * ccdc64f Clarify start of Section 4.5, anydata
> >>
> >> I want to thanks all the contributors, the early ones and those dedicated enough to bring this draft to the Finish Line.
> >>
> >> Regards,
> >> Michel Veillette
> >
> > Below, I have summarized what these three changes entail:
> >
> > (1)
> > In section 6.7, the sentence "Leafs of type bits MUST be encoded either using a CBOR array or byte string (major type 2) ."
> >
> > Does not mention the major type - every similar sentence does, so we 
> > propose changing this to
> >
> > "Leafs of type bits MUST be encoded either using a CBOR array (major type 4) or byte string (major type 2)  ."
> >
> > We changed this in
> >
> > https://can01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpr
> > otect2.fireeye.com%2Fv1%2Furl%3Fk%3D31323334-501d5122-313273af-45444
> > 5555731-55f2033e628b259d%26q%3D1%26e%3D4b10d94f-4488-4a9e-9319-0a8e9
> > c4a67d6%26u%3Dhttps%253A%252F%252Fgithub.com%252Fcore-wg%252Fyang-cb
> > or%252Fblob%252Fauth48%252Fauth48%252Frfc9254.xml&amp;data=05%7C01%7
> > CMichel.Veillette%40trilliant.com%7Ca926d83aba074585913d08da6344faa3
> > %7C4f6fbd130dfb415085c3d43260c04309%7C0%7C0%7C637931446299127670%7CU
> > nknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1
> > haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&amp;sdata=8J%2BOc53D7b7nCFVApk03
> > ZnL2U6rknTJe1MBN11pSFCk%3D&amp;reserved=0
> > specifically:
> > https://can01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpr
> > otect2.fireeye.com%2Fv1%2Furl%3Fk%3D31323334-501d5122-313273af-45444
> > 5555731-ceb67e98f4392d40%26q%3D1%26e%3D4b10d94f-4488-4a9e-9319-0a8e9
> > c4a67d6%26u%3Dhttps%253A%252F%252Fgithub.com%252Fcore-wg%252Fyang-cb
> > or%252Fcommit%252Fdd233ef&amp;data=05%7C01%7CMichel.Veillette%40tril
> > liant.com%7Ca926d83aba074585913d08da6344faa3%7C4f6fbd130dfb415085c3d
> > 43260c04309%7C0%7C0%7C637931446299127670%7CUnknown%7CTWFpbGZsb3d8eyJ
> > WIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C30
> > 00%7C%7C%7C&amp;sdata=r1%2FRSvf4JCgEgunIjwpgyx7%2B3xkmjPvfC00C6FYHt8
> > Y%3D&amp;reserved=0
> >
> > (2)
> > In the entire document, we have different ways of indicating where the examples come from.
> >
> > The document contains 3 instances of "Definition example adapted from ..."
> > The document contains 1 instances of "Definition example (adapted from ..."
> > The document contains 1 instance of "Definition example simplified from"...
> > The document contains 14 instances of "Definition example from ..."
> >
> > We should standardize to "Definition example adapted from ..."
> >
> > We changed this in
> >
> > https://can01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpr
> > otect2.fireeye.com%2Fv1%2Furl%3Fk%3D31323334-501d5122-313273af-45444
> > 5555731-55f2033e628b259d%26q%3D1%26e%3D4b10d94f-4488-4a9e-9319-0a8e9
> > c4a67d6%26u%3Dhttps%253A%252F%252Fgithub.com%252Fcore-wg%252Fyang-cb
> > or%252Fblob%252Fauth48%252Fauth48%252Frfc9254.xml&amp;data=05%7C01%7
> > CMichel.Veillette%40trilliant.com%7Ca926d83aba074585913d08da6344faa3
> > %7C4f6fbd130dfb415085c3d43260c04309%7C0%7C0%7C637931446299127670%7CU
> > nknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1
> > haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&amp;sdata=8J%2BOc53D7b7nCFVApk03
> > ZnL2U6rknTJe1MBN11pSFCk%3D&amp;reserved=0
> > specifically:
> > https://can01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpr
> > otect2.fireeye.com%2Fv1%2Furl%3Fk%3D31323334-501d5122-313273af-45444
> > 5555731-13b4e07bd7a9ae21%26q%3D1%26e%3D4b10d94f-4488-4a9e-9319-0a8e9
> > c4a67d6%26u%3Dhttps%253A%252F%252Fgithub.com%252Fcore-wg%252Fyang-cb
> > or%252Fcommit%252F07d3a4c&amp;data=05%7C01%7CMichel.Veillette%40tril
> > liant.com%7Ca926d83aba074585913d08da6344faa3%7C4f6fbd130dfb415085c3d
> > 43260c04309%7C0%7C0%7C637931446299127670%7CUnknown%7CTWFpbGZsb3d8eyJ
> > WIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C30
> > 00%7C%7C%7C&amp;sdata=rEikJQFztq4cT%2FABAXypayD7KfbTg51A9A%2BvLufpZS
> > k%3D&amp;reserved=0
> >
> > (3)
> > We found the bullet list at the start of 4.5 confusing and hard to fix.
> > We decided that the best fix is to simply not to repeat the material 
> > that is already in 4.2, but to instead point to that.
> > Removing the text that is trying to be redundant actually is an 
> > editorial change, in lieu of making a number of risky editorial 
> > changes to the items in the bullet list.
> >
> > This simplification is laid out in:
> >
> > https://can01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpr
> > otect2.fireeye.com%2Fv1%2Furl%3Fk%3D31323334-501d5122-313273af-45444
> > 5555731-55f2033e628b259d%26q%3D1%26e%3D4b10d94f-4488-4a9e-9319-0a8e9
> > c4a67d6%26u%3Dhttps%253A%252F%252Fgithub.com%252Fcore-wg%252Fyang-cb
> > or%252Fblob%252Fauth48%252Fauth48%252Frfc9254.xml&amp;data=05%7C01%7
> > CMichel.Veillette%40trilliant.com%7Ca926d83aba074585913d08da6344faa3
> > %7C4f6fbd130dfb415085c3d43260c04309%7C0%7C0%7C637931446299127670%7CU
> > nknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1
> > haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&amp;sdata=8J%2BOc53D7b7nCFVApk03
> > ZnL2U6rknTJe1MBN11pSFCk%3D&amp;reserved=0
> > specifically:
> > https://can01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpr
> > otect2.fireeye.com%2Fv1%2Furl%3Fk%3D31323334-501d5122-313273af-45444
> > 5555731-929bc5aa5f37fe23%26q%3D1%26e%3D4b10d94f-4488-4a9e-9319-0a8e9
> > c4a67d6%26u%3Dhttps%253A%252F%252Fgithub.com%252Fcore-wg%252Fyang-cb
> > or%252Fcommit%252Fccdc64f&amp;data=05%7C01%7CMichel.Veillette%40tril
> > liant.com%7Ca926d83aba074585913d08da6344faa3%7C4f6fbd130dfb415085c3d
> > 43260c04309%7C0%7C0%7C637931446299127670%7CUnknown%7CTWFpbGZsb3d8eyJ
> > WIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C30
> > 00%7C%7C%7C&amp;sdata=rcHH0BTNeiY0TMRLMkqQznExjtgyrMBjKiyJUVM%2FSak%
> > 3D&amp;reserved=0
> >
> > Thank you.
> >
> > Grüße, Carsten
> >