[AFS3-std] Request for allocation of capability bit
Jeffrey E Altman
jaltman@auristor.com
Thu, 25 May 2023 22:31:10 -0400
This is a cryptographically signed message in MIME format.
--------------ms040907050307020108010808
Content-Type: multipart/alternative;
boundary="------------j0v57A5IfAxAcgoRBogp0TaL"
--------------j0v57A5IfAxAcgoRBogp0TaL
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
On 5/25/2023 7:35 PM, Marcio Barbosa wrote:
> Hello everyone,
Hello Marcio,
> I hope this email finds you well. I am writing to inform you that I have recently
> published an internet draft requesting the allocation of a new capability bit.
>
> The internet draft, titled "Introduce VLDB_CAPABILITY_LOCKTIMESTAMP", is now
> available and can be found at the following location:
>
> https://www.ietf.org/archive/id/draft-barbosa-afs3-vlcapabilities-lock-00.txt
Thank you for publishing the I-D which might be misnamed. The I-D
proposes changes to two existing structures defined in
src/vlserver/vldbint.xg and the operation of the RPCs that pass the
structures as parameters. The affected types are:
* struct nvldbentry
* nbulkentries
* struct uvldbentry
The affected RPCs are:
* VL_GetEntryByNameN (OUT)
* VL_CreateEntryN (IN)
* VL_GetEntryByIDN (OUT)
* VL_ReplaceEntryN (IN)
* VL_ListEntryN (OUT)
* VL_ListAttributesN (OUT)
* VL_ListAttributesN2 (OUT)
* VL_GetEntryByIDU (OUT)
The proposal is that the following structure fields which are currently
reserved and are required to be zero be repurposed to store a 32-bit
timestamp representing the time a lock was issued.
* struct nvldbentry.spares2
* struct uvldbentry.spares2
Although it is true that IBM as part of the AFS 3.5 release repurposed
struct nvldbentry.spares1 as nvldbentry.matchindex the field is only
defined for use as part of a new RPC: VL_ListAttributesN2. Best
practice is not to modify the semantics of the structures used in
existing RPCs. Instead, new RPCs should be allocated to indicate that
the caller understands the new semantics. If the new RPC is supported
by the server, then it will be executed with the expected semantics.
Otherwise, RXGEN_OPCODE is returned indicating to the caller that the
requested functionality is unavailable. The caller then falls back to
an older version of the RPC.
In general, service capability bits should not be used for the purpose
of altering the behavior of existing RPCs. The allocation of
CLiENT_CAPABILITY_ERRORTRANS when queried by the fileserver is used to
alter the output of RXAFS RPCs based upon whether or not the client
understands the portable UAE error tables. The
VICED_CAPABILITY_ERRORTRANS informs the client whether or not the server
is capable of returning UAE error codes. If
VICED_CAPABILITY_ERRORTRANS is unavailable the client needs to be
careful with processing the return codes because the fileserver's OS
error code assignments might not match those of the caller.
Service capability bits for UBIK services are particularly problematic
because there is no requirement that all servers in the cell run the
same version. Lets say that VL_CAPABILITY_LOCKTIMESTAMP was allocated
for the purpose of indicating that nvldbentry.spares2 is a non-zero
timestamp value if the entry is locked. There is no guarantee that the
VL_GetCapabilities RPC result will be returned from the same server that
responded to the VL_GetEntryByIDN RPC. If VL_CAPABILITY_LOCKTIMESTAMP
was set on the server that responded to VL_GetCapabilities but the
server responding to VL_GetEntryByIDN is older and doesn't support that
behavior, then the caller might believe that the zero nvldbentry.spares2
field indicates that the entry isn't locked.
For UBIK services, the callers are not told which server responded to a
given RPC. The only way of knowing if a new behavior was supported is
to issue a new RPC and fallback to an older RPC if it is unavailable.
The nvldbentry and uvldbentry structures are used as both input and
output parameters. This is because the way a client such as vos makes
a change to the database entry is by fetching the current entry,
modifying it, and writing it back to the server. Any specification that
documents the new use of the field must indicate how the server is
expected to handle the field when the structure is provided as input to
the vlserver.
Since its introduction the spare2 field of struct nvldbentry and
uvldbentry has always been set to zero when returned from the vlserver.
If a vlserver was to set this value to a non-zero value, there would be
no confusion for a caller that received it. While I am not in favor of
modifying the semantics of existing RPCs, in this case returning the
lock timestamp would not be harmful assuming that no one ever stole the
selected field for a private use thinking it would never be used.
For the reasons described above I do not believe that allocation of the
VL_CAPABILITY bit is warranted.
The I-D says that one of the motivations for auditing and
troubleshooting. I will caution that because the VL service is UBIK,
there is no guarantee that a VL RPC returning a nvldbentry or uvldentry
was answered by the coordinator that it is not safe to trust any lock
state including a lock timestamp. I am aware of proposals that have
been made to use VL debugging RPCs to identify which server is the
coordinator for the purpose of issuing RPCs solely to the coordinator.
However, such an approach is racy. The coordinator's term can expire
immediately following the response to the debugging RPC. Therefore, the
results from such an approach cannot be trusted.
I hope you find this feedback useful.
As I am not familiar with the current status of the AFS3 standardization
process I will defer to someone else to respond to the question of
timelines and milestones for standardization.
Allocation registries are maintained by registrar@grand.central.org.
See https://registrar.central.org.
Sincerely,
Jeffrey Altman
--------------j0v57A5IfAxAcgoRBogp0TaL
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 8bit
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<div class="moz-cite-prefix">On 5/25/2023 7:35 PM, Marcio Barbosa
wrote:<br>
</div>
<blockquote type="cite"
cite="mid:9936072D-5A74-4D22-860E-1B8E72639C3C@sinenomine.net">
<pre class="moz-quote-pre" wrap="">Hello everyone,</pre>
</blockquote>
<p>Hello Marcio,
</p>
<blockquote type="cite"
cite="mid:9936072D-5A74-4D22-860E-1B8E72639C3C@sinenomine.net">
<pre class="moz-quote-pre" wrap="">I hope this email finds you well. I am writing to inform you that I have recently
published an internet draft requesting the allocation of a new capability bit.
The internet draft, titled "Introduce VLDB_CAPABILITY_LOCKTIMESTAMP", is now
available and can be found at the following location:
<a class="moz-txt-link-freetext" href="https://www.ietf.org/archive/id/draft-barbosa-afs3-vlcapabilities-lock-00.txt">https://www.ietf.org/archive/id/draft-barbosa-afs3-vlcapabilities-lock-00.txt</a></pre>
</blockquote>
<p>Thank you for publishing the I-D which might be misnamed. The
I-D proposes changes to two existing structures defined in
src/vlserver/vldbint.xg and the operation of the RPCs that pass
the structures as parameters. The affected types are:<br>
</p>
<ul>
<li>struct nvldbentry</li>
<li>nbulkentries</li>
<li>struct uvldbentry<br>
</li>
</ul>
<p>The affected RPCs are:</p>
<ul>
<li>VL_GetEntryByNameN (OUT)<br>
</li>
<li>VL_CreateEntryN (IN)<br>
</li>
<li>VL_GetEntryByIDN (OUT)<br>
</li>
<li>VL_ReplaceEntryN (IN)<br>
</li>
<li>VL_ListEntryN (OUT)<br>
</li>
<li>VL_ListAttributesN (OUT)<br>
</li>
<li>VL_ListAttributesN2 (OUT)</li>
<li>VL_GetEntryByIDU (OUT)<br>
</li>
</ul>
<p>The proposal is that the following structure fields which are
currently reserved and are required to be zero be repurposed to
store a 32-bit timestamp representing the time a lock was issued.</p>
<ul>
<li>struct nvldbentry.spares2</li>
<li>struct uvldbentry.spares2</li>
</ul>
<p>Although it is true that IBM as part of the AFS 3.5 release
repurposed struct nvldbentry.spares1 as nvldbentry.matchindex the
field is only defined for use as part of a new RPC:
VL_ListAttributesN2. Best practice is not to modify the semantics
of the structures used in existing RPCs. Instead, new RPCs should
be allocated to indicate that the caller understands the new
semantics. If the new RPC is supported by the server, then it
will be executed with the expected semantics. Otherwise,
RXGEN_OPCODE is returned indicating to the caller that the
requested functionality is unavailable. The caller then falls
back to an older version of the RPC.</p>
<p>In general, service capability bits should not be used for the
purpose of altering the behavior of existing RPCs. The
allocation of CLiENT_CAPABILITY_ERRORTRANS when queried by the
fileserver is used to alter the output of RXAFS RPCs based upon
whether or not the client understands the portable UAE error
tables. The VICED_CAPABILITY_ERRORTRANS informs the client
whether or not the server is capable of returning UAE error
codes. If VICED_CAPABILITY_ERRORTRANS is unavailable the client
needs to be careful with processing the return codes because the
fileserver's OS error code assignments might not match those of
the caller.</p>
<p>Service capability bits for UBIK services are particularly
problematic because there is no requirement that all servers in
the cell run the same version. Lets say that
VL_CAPABILITY_LOCKTIMESTAMP was allocated for the purpose of
indicating that nvldbentry.spares2 is a non-zero timestamp value
if the entry is locked. There is no guarantee that the
VL_GetCapabilities RPC result will be returned from the same
server that responded to the VL_GetEntryByIDN RPC. If
VL_CAPABILITY_LOCKTIMESTAMP was set on the server that responded
to VL_GetCapabilities but the server responding to
VL_GetEntryByIDN is older and doesn't support that behavior, then
the caller might believe that the zero nvldbentry.spares2 field
indicates that the entry isn't locked.</p>
<p>For UBIK services, the callers are not told which server
responded to a given RPC. The only way of knowing if a new
behavior was supported is to issue a new RPC and fallback to an
older RPC if it is unavailable.</p>
<p>The nvldbentry and uvldbentry structures are used as both input
and output parameters. This is because the way a client such as
vos makes a change to the database entry is by fetching the
current entry, modifying it, and writing it back to the server.
Any specification that documents the new use of the field must
indicate how the server is expected to handle the field when the
structure is provided as input to the vlserver.</p>
<p>Since its introduction the spare2 field of struct nvldbentry and
uvldbentry has always been set to zero when returned from the
vlserver. If a vlserver was to set this value to a non-zero
value, there would be no confusion for a caller that received it.
While I am not in favor of modifying the semantics of existing
RPCs, in this case returning the lock timestamp would not be
harmful assuming that no one ever stole the selected field for a
private use thinking it would never be used.<br>
</p>
<p>For the reasons described above I do not believe that allocation
of the VL_CAPABILITY bit is warranted. <br>
</p>
<p>The I-D says that one of the motivations for auditing and
troubleshooting. I will caution that because the VL service is
UBIK, there is no guarantee that a VL RPC returning a nvldbentry
or uvldentry was answered by the coordinator that it is not safe
to trust any lock state including a lock timestamp. I am aware
of proposals that have been made to use VL debugging RPCs to
identify which server is the coordinator for the purpose of
issuing RPCs solely to the coordinator. However, such an approach
is racy. The coordinator's term can expire immediately following
the response to the debugging RPC. Therefore, the results from
such an approach cannot be trusted.</p>
<p>I hope you find this feedback useful.</p>
<p>As I am not familiar with the current status of the AFS3
standardization process I will defer to someone else to respond to
the question of timelines and milestones for standardization.<br>
</p>
<p>Allocation registries are maintained by
<a class="moz-txt-link-abbreviated" href="mailto:registrar@grand.central.org">registrar@grand.central.org</a>. See <a class="moz-txt-link-freetext" href="https://registrar.central.org">https://registrar.central.org</a>.</p>
<p>Sincerely,</p>
<p>Jeffrey Altman</p>
<p><br>
</p>
<p><br>
</p>
<p></p>
</body>
</html>
--------------j0v57A5IfAxAcgoRBogp0TaL--
--------------ms040907050307020108010808
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature
MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC
DHEwggXSMIIEuqADAgECAhBAAYJpmi/rPn/F0fJyDlzMMA0GCSqGSIb3DQEBCwUAMDoxCzAJ
BgNVBAYTAlVTMRIwEAYDVQQKEwlJZGVuVHJ1c3QxFzAVBgNVBAMTDlRydXN0SUQgQ0EgQTEz
MB4XDTIyMDgwNDE2MDQ0OFoXDTI1MTAzMTE2MDM0OFowcDEvMC0GCgmSJomT8ixkAQETH0Ew
MTQxMEQwMDAwMDE4MjY5OUEyRkQyMDAwMjMzQ0QxGTAXBgNVBAMTEEplZmZyZXkgRSBBbHRt
YW4xFTATBgNVBAoTDEF1cmlTdG9yIEluYzELMAkGA1UEBhMCVVMwggEiMA0GCSqGSIb3DQEB
AQUAA4IBDwAwggEKAoIBAQCkC7PKBBZnQqDKPtZPMLAy77zo2DPvwtGnd1hNjPvbXrpGxUb3
xHZRtv179LHKAOcsY2jIctzieMxf82OMyhpBziMPsFAG/ukihBMFj3/xEeZVso3K27pSAyyN
fO/wJ0rX7G+ges22Dd7goZul8rPaTJBIxbZDuaykJMGpNq4PQ8VPcnYZx+6b+nJwJJoJ46kI
EEfNh3UKvB/vM0qtxS690iAdgmQIhTl+qfXq4IxWB6b+3NeQxgR6KLU4P7v88/tvJTpxIKkg
9xj89ruzeThyRFd2DSe3vfdnq9+g4qJSHRXyTft6W3Lkp7UWTM4kMqOcc4VSRdufVKBQNXjG
IcnhAgMBAAGjggKcMIICmDAOBgNVHQ8BAf8EBAMCBPAwgYQGCCsGAQUFBwEBBHgwdjAwBggr
BgEFBQcwAYYkaHR0cDovL2NvbW1lcmNpYWwub2NzcC5pZGVudHJ1c3QuY29tMEIGCCsGAQUF
BzAChjZodHRwOi8vdmFsaWRhdGlvbi5pZGVudHJ1c3QuY29tL2NlcnRzL3RydXN0aWRjYWEx
My5wN2MwHwYDVR0jBBgwFoAULbfeG1l+KpguzeHUG+PFEBJe6RQwCQYDVR0TBAIwADCCASsG
A1UdIASCASIwggEeMIIBGgYLYIZIAYb5LwAGAgEwggEJMEoGCCsGAQUFBwIBFj5odHRwczov
L3NlY3VyZS5pZGVudHJ1c3QuY29tL2NlcnRpZmljYXRlcy9wb2xpY3kvdHMvaW5kZXguaHRt
bDCBugYIKwYBBQUHAgIwga0MgapUaGlzIFRydXN0SUQgQ2VydGlmaWNhdGUgaGFzIGJlZW4g
aXNzdWVkIGluIGFjY29yZGFuY2Ugd2l0aCBJZGVuVHJ1c3QncyBUcnVzdElEIENlcnRpZmlj
YXRlIFBvbGljeSBmb3VuZCBhdCBodHRwczovL3NlY3VyZS5pZGVudHJ1c3QuY29tL2NlcnRp
ZmljYXRlcy9wb2xpY3kvdHMvaW5kZXguaHRtbDBFBgNVHR8EPjA8MDqgOKA2hjRodHRwOi8v
dmFsaWRhdGlvbi5pZGVudHJ1c3QuY29tL2NybC90cnVzdGlkY2FhMTMuY3JsMB8GA1UdEQQY
MBaBFGphbHRtYW5AYXVyaXN0b3IuY29tMB0GA1UdDgQWBBQB+nzqgljLocLTsiUn2yWqEc2s
gjAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwDQYJKoZIhvcNAQELBQADggEBAJwV
eycprp8Ox1npiTyfwc5QaVaqtoe8Dcg2JXZc0h4DmYGW2rRLHp8YL43snEV93rPJVk6B2v4c
WLeQfaMrnyNeEuvHx/2CT44cdLtaEk5zyqo3GYJYlLcRVz6EcSGHv1qPXgDT0xB/25etwGYq
utYF4Chkxu4KzIpq90eDMw5ajkexw+8ARQz4N5+d6NRbmMCovd7wTGi8th/BZvz8hgKUiUJo
Qle4wDxrdXdnIhCP7g87InXKefWgZBF4VX21t2+hkc04qrhIJlHrocPG9mRSnnk2WpsY0MXt
a8ivbVKtfpY7uSNDZSKTDi1izEFH5oeQdYRkgIGb319a7FjslV8wggaXMIIEf6ADAgECAhBA
AXA7OrqBjMk8rp4OuNQSMA0GCSqGSIb3DQEBCwUAMEoxCzAJBgNVBAYTAlVTMRIwEAYDVQQK
EwlJZGVuVHJ1c3QxJzAlBgNVBAMTHklkZW5UcnVzdCBDb21tZXJjaWFsIFJvb3QgQ0EgMTAe
Fw0yMDAyMTIyMTA3NDlaFw0zMDAyMTIyMTA3NDlaMDoxCzAJBgNVBAYTAlVTMRIwEAYDVQQK
EwlJZGVuVHJ1c3QxFzAVBgNVBAMTDlRydXN0SUQgQ0EgQTEzMIIBIjANBgkqhkiG9w0BAQEF
AAOCAQ8AMIIBCgKCAQEAu6sUO01SDD99PM+QdZkNxKxJNt0NgQE+Zt6ixaNP0JKSjTd+SG5L
wqxBWjnOgI/3dlwgtSNeN77AgSs+rA4bK4GJ75cUZZANUXRKw/et8pf9Qn6iqgB63OdHxBN/
15KbM3HR+PyiHXQoUVIevCKW8nnlWnnZabT1FejOhRRKVUg5HACGOTfnCOONrlxlg+m1Vjgn
o1uNqNuLM/jkD1z6phNZ/G9IfZGI0ppHX5AA/bViWceX248VmefNhSR14ADZJtlAAWOi2un0
3bqrBPHA9nDyXxI8rgWLfUP5rDy8jx2hEItg95+ORF5wfkGUq787HBjspE86CcaduLka/Bk2
VwIDAQABo4IChzCCAoMwEgYDVR0TAQH/BAgwBgEB/wIBADAOBgNVHQ8BAf8EBAMCAYYwgYkG
CCsGAQUFBwEBBH0wezAwBggrBgEFBQcwAYYkaHR0cDovL2NvbW1lcmNpYWwub2NzcC5pZGVu
dHJ1c3QuY29tMEcGCCsGAQUFBzAChjtodHRwOi8vdmFsaWRhdGlvbi5pZGVudHJ1c3QuY29t
L3Jvb3RzL2NvbW1lcmNpYWxyb290Y2ExLnA3YzAfBgNVHSMEGDAWgBTtRBnA0/AGi+6ke75C
5yZUyI42djCCASQGA1UdIASCARswggEXMIIBEwYEVR0gADCCAQkwSgYIKwYBBQUHAgEWPmh0
dHBzOi8vc2VjdXJlLmlkZW50cnVzdC5jb20vY2VydGlmaWNhdGVzL3BvbGljeS90cy9pbmRl
eC5odG1sMIG6BggrBgEFBQcCAjCBrQyBqlRoaXMgVHJ1c3RJRCBDZXJ0aWZpY2F0ZSBoYXMg
YmVlbiBpc3N1ZWQgaW4gYWNjb3JkYW5jZSB3aXRoIElkZW5UcnVzdCdzIFRydXN0SUQgQ2Vy
dGlmaWNhdGUgUG9saWN5IGZvdW5kIGF0IGh0dHBzOi8vc2VjdXJlLmlkZW50cnVzdC5jb20v
Y2VydGlmaWNhdGVzL3BvbGljeS90cy9pbmRleC5odG1sMEoGA1UdHwRDMEEwP6A9oDuGOWh0
dHA6Ly92YWxpZGF0aW9uLmlkZW50cnVzdC5jb20vY3JsL2NvbW1lcmNpYWxyb290Y2ExLmNy
bDAdBgNVHQ4EFgQULbfeG1l+KpguzeHUG+PFEBJe6RQwHQYDVR0lBBYwFAYIKwYBBQUHAwIG
CCsGAQUFBwMEMA0GCSqGSIb3DQEBCwUAA4ICAQB/7BKcygLX6Nl4a03cDHt7TLdPxCzFvDF2
bkVYCFTRX47UfeomF1gBPFDee3H/IPlLRmuTPoNt0qjdpfQzmDWN95jUXLdLPRToNxyaoB5s
0hOhcV6H08u3FHACBif55i0DTDzVSaBv0AZ9h1XeuGx4Fih1Vm3Xxz24GBqqVudvPRLyMJ7u
6hvBqTIKJ53uCs3dyQLZT9DXnp+kJv8y7ZSAY+QVrI/dysT8avtn8d7k7azNBkfnbRq+0e88
QoBnel6u+fpwbd5NLRHywXeH+phbzULCa+bLPRMqJaW2lbhvSWrMHRDy3/d8HvgnLCBFK2s4
Spns4YCN4xVcbqlGWzgolHCKUH39vpcsDo1ymZFrJ8QR6ihIn8FmJ5oKwAnnd/G6ADXFC9bu
db9+532phSAXOZrrecIQn+vtP366PC+aClAPsIIDJDsotS5z4X2JUFsNIuEgXGqhiKE7SuZb
rFG9sdcLprSlJN7TsRDc0W2b9nqwD+rj/5MN0C+eKwha+8ydv0+qzTyxPP90KRgaegGowC4d
UsZyTk2n4Z3MuAHX5nAZL/Vh/SyDj/ajorV44yqZBzQ3ChKhXbfUSwe2xMmygA2Z5DRwMRJn
p/BscizYdNk2WXJMTnH+wVLN8sLEwEtQR4eTLoFmQvrK2AMBS9kW5sBkMzINt/ZbbcZ3F+eA
MDGCAxQwggMQAgEBME4wOjELMAkGA1UEBhMCVVMxEjAQBgNVBAoTCUlkZW5UcnVzdDEXMBUG
A1UEAxMOVHJ1c3RJRCBDQSBBMTMCEEABgmmaL+s+f8XR8nIOXMwwDQYJYIZIAWUDBAIBBQCg
ggGXMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTIzMDUyNjAy
MzExMFowLwYJKoZIhvcNAQkEMSIEIF1NSIBYKtiqI53F8WLRWVIAZJYQXH3StlcEgj5t4+3N
MF0GCSsGAQQBgjcQBDFQME4wOjELMAkGA1UEBhMCVVMxEjAQBgNVBAoTCUlkZW5UcnVzdDEX
MBUGA1UEAxMOVHJ1c3RJRCBDQSBBMTMCEEABgmmaL+s+f8XR8nIOXMwwXwYLKoZIhvcNAQkQ
AgsxUKBOMDoxCzAJBgNVBAYTAlVTMRIwEAYDVQQKEwlJZGVuVHJ1c3QxFzAVBgNVBAMTDlRy
dXN0SUQgQ0EgQTEzAhBAAYJpmi/rPn/F0fJyDlzMMGwGCSqGSIb3DQEJDzFfMF0wCwYJYIZI
AWUDBAEqMAsGCWCGSAFlAwQBAjAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZI
hvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwDQYJKoZIhvcNAQEBBQAEggEABBMm
OFtRvwqcdAz43FhRGevC4uS4u6eU+wirCrGAyjLVzB+TA/ofFaTpphvg9XZIvfukDoeV3boK
EiHg4iS+EdTKRViEpTWb74fq+zy0z8lAoRUkIo22MZyl7AJRvUGTHRnl3A+e0shc1e5PN7/3
FihzIVEmkkGlPYOiPHFM26OnEPDrjN9K8NfHhTuer+T1gAaJLqd37FZOMT23xhipYNKp/raj
2Aeb89MTiJS/JX53zwxJXHx7qK8ciYFkjhgN9S+FC3ceV2yr3XbMWC2OKG3qkwets5E44qJc
rziXe3JefzMRHilABR1QjrZVRRYHGk2cPRZKnLpmDqC0mN1o9gAAAAAAAA==
--------------ms040907050307020108010808--