Progress Indication function in Device Busy Event#2

Henry Gabryjelski henrygab at windows.microsoft.com
Mon Nov 3 07:49:54 PST 2003


* From the T10 Reflector (t10 at t10.org), posted by:
* "Henry Gabryjelski" <henrygab at windows.microsoft.com>
*
This is a multi-part message in MIME format.

------=_NextPart_000_003D_01C3A1DF.118F78A0
Content-Type: multipart/alternative;
	boundary="----=_NextPart_001_003E_01C3A1DF.118F78A0"


------=_NextPart_001_003E_01C3A1DF.118F78A0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit

(Due to many issue with asynchronous GESN, it will not be considered in this
response.  Also, command queuing in CD type logical units will similiarly
not be considered.)

1) Indeed, the initiator of any command (referred to below as the host, but
may be driver or application, but rarely both) can know the remaining time
using the command-specific follow-up behavior. 

2) If Device Busy is used to indicate timeout possibility of a command, what
commands are covered by the Device Busy event?  I will presume that only
those commands which can timeout per spec are included.  In such a case,
what will occur if the device cannot accept one command but can accept a
second command?  Which command's timeout value will be reported in the
Device Busy event?

The documentation on Device Busy supports may be interpreted to support this
notion of use for Device Busy event for a transport/device that supports
command queueing.  In these cases, it is clear how the Device Busy event
could be used in the method described by Katata-san.  However, in a
single-command transport/device, the use model described does not seem to be
easily supported.  Using Katata-san's section 2.3 for diagrams:

Method 1 works for non-queued, single-command at a time case.  However, only
the initiator of the command (either one application or driver, not both)
can understand the results.  Method 2 will not be considered.  The diagram
of Method 4 is unclear, and not referred to in this discussion.  This leaves
only Method 3 per Katata-san's documentation.

Method 3 is the most interesting of the cases. In a non-queued environment,
the READ command would timeout; Since the specification says timeouts are
disabled, there are three scenarios:  (A) device becomes ready to receive
next command, (B) device continues to asset the busy bit (ATAPI example)
saying it is not ready for next command, (C) host sends GESN prior to READ
command to get Device Busy. In case B, the host will eventually force the
command to terminate due to the command's timeout setting.  I do not believe
this could be the intention of the specification.

In case A, the host will expect the data to have been successfully written.
Furthermore, in a complex host environment, it is not possible to ensure
that a GESN event will follow each command.  One example is when an
operating system implicitly allows commands (I/O) to be reordered within a
device driver stack, or have I/O inserted between existing commands.
Therefore, it is quite possible and even likely that a complex host would
not send a GESN event immediately following such a command and therefore
never get the Device Busy event.

Before discussing case C at length, I must first quote from MMC3r1.0g:
"This type of event is usable in two environments. The first is in a queued
environment. The GET
EVENT/STATUS NOTIFICATION command may be issued in a non-immediate mode
prior to executing
commands or in the immediate mode while commands are being executed. The
second environment is
where immediate commands and deferred writing are performed; this command
may be issued in the
immediate mode to obtain status. If a normal command is issued while the
device is busy, this command
cannot be issued until the normal command completes. Therefore, if queuing
is not used, the GET
EVENT/STATUS NOTIFICATION command should precede any command that may time
out."

The specific example of the write/read commands is not a good example, as
the LU cannot know what the next command the device will receive.
Therefore, it cannot know the correct Device Busy time to put into the
event.  For example, a series of WRITE commands would not report a Device
Busy event between any of those commands in many cases.  However, if a READ
command were inserted into that sequence, a Device Busy event may be
required per the diagram in the document.  Therefore, I think it is not
possible for a LU to implement this because the LU cannot know the next
command that will be sent to the device.

Instead, let us consider case C for another type of command that takes an
abnormally long time to complete (Format Unit, Blank, Close Track/Session,
etc., always considered with IMMED=1).  In these cases, one can read the
above MMC3 section as stating that any GESN Device Busy request received by
the LU shall report the time from the receipt of the GESN command until the
LU will be able to handle additional commands.  While Katata-san describes
this as "progress", the real information contained in the event is only the
amount of time until the LU is ready to process additional commands.

>From here, I think there are two possible paths that devices can follow.
The first is, when such a long command is executing, that the LU reports a
zero value, as commands will be failed with 2/4/7 or 2/4/8 as necessary.  In
such a case, the Device Busy events are meaningless, so let us not consider
this as a correct solutiuon.  The second path is that the LU reports the
approximate time to the completion of the long immediate command.  In this
case, the host can use this information.  In fact, with proper driver
software, all drivers and software can be simultaneously informed of the
time until the LU is no longer busy.  (This is what the MMCTest provided by
Microsoft's WHQL has been using during BLANK, FORMAT UNIT, and CLOSE
SESSION/TRACK command testing for some time.)

Comments and questions are welcome.
.



-----Original Message-----
From: owner-mtfuji5 at avc-pioneer.com [mailto:owner-mtfuji5 at avc-pioneer.com]
On Behalf Of Kenji Tokumitsu
Sent: Saturday, November 01, 2003 12:09 AM
To: twg3 at ml.cds21solutions.org; T10 at t10.org
Cc: mtfuji5 at avc-pioneer.com
Subject: RE: Progress Indication function in Device Busy Event#2

Hello all,

The followings are my comments.

1. Progress indication
 In my understanding, the host cannot know the remaining time directly from
the drive.
 Host can know a progress indication by percent.
 Katata-san described that "Host converts the percentage to the assumed
remaining time....".

 Is there any problem in such a remainig time estimation method ?
 I cannot understand what is the problem.
 If someone says "The problem is that the host cannot estimate the accurate
remaining time.",
 I say "The drive does not know the accurate remaining time.".
 So, I think the current esimation method has no problem.
 And I think the current estimation method is easy way for host because host
can indicate both
 progress indication by percent and estimated remaining time from one
information.

2. Time field of Device Busy Event
 In my understanding, Time field of Device Busy Event of GESN is to report
the expanded working time for not becoming a timeout.
 The remaining processing time is not reported.
 If misunderstanding is produced in the current description, we should
change description so that misunderstanding may not occur.

Best Regards,

Kenji Tokumitsu
Hitachi-LG Data Storage, Inc.

-----Original Message-----
From: keiji_katata at post.pioneer.co.jp
[mailto:keiji_katata at post.pioneer.co.jp]
Sent: Friday, October 31, 2003 7:21 PM
To: T10 at t10.org
Cc: mtfuji5 at avc-pioneer.com; twg3 at ml.cds21solutions.org
Subject: Progress Indication function in Device Busy Event#2



Hello all,

I put CONSIDERATION.DOC in ftp.avc-pioneer.com/MtFuji5/Proposal/Nov03.
I correct the file name and add a section "2.5 Event lost possibility of
OS".

Please check my consideration and send me your comment.

Best regards,

Keiji Katata
PIONEER CORP.







------=_NextPart_001_003E_01C3A1DF.118F78A0
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">

 RE: Progress Indication function in Device Busy Event#2 (Due to many = issue with asynchronous GESN, it will not be considered in this = response.  Also, command queuing in CD type logical units will = similiarly not be considered.) 1) Indeed, = the initiator of any command (referred to below as the host, but may be = driver or application, but rarely both) can know the remaining time = using the command-specific follow-up behavior. 2) If Device = Busy is used to indicate timeout possibility of a command, what commands = are covered by the Device Busy event?  I will presume that only = those commands which can timeout per spec are included.  In such a = case, what will occur if the device cannot accept one command but can = accept a second command?  Which command's timeout value will be = reported in the Device Busy event? The = documentation on Device Busy supports may be interpreted to support this = notion of use for Device Busy event for a transport/device that supports = command queueing.  In these cases, it is clear how the Device Busy = event could be used in the method described by Katata-san.  = However, in a single-command transport/device, the use model described = does not seem to be easily supported.  Using Katata-san's = section 2.3 for diagrams: Method 1 = works for non-queued, single-command at a time case.  However, only = the initiator of the command (either one application or = driver, not = both) can understand the = results.  Method 2 will not be considered.  The diagram of = Method 4 is unclear, and not referred to in this discussion.  This = leaves only Method 3 per Katata-san's documentation. Method = 3 is the most interesting = of the cases. In a non-queued environment, the READ command would = timeout; Since the specification says timeouts are disabled, there are = three scenarios:  (A) device becomes ready to receive next command, = (B) device continues to asset the busy bit (ATAPI example) saying it is = not ready for next command, (C) host sends GESN prior to READ command to = get Device Busy. In case = B, the host will = eventually force the command to terminate due to the command's timeout = setting.  I do not believe this could be the intention of the = specification. In = case A, the host will expect the data to have been = successfully written.  Furthermore, in a complex host environment, = it is not possible to ensure that a GESN event will follow each = command.  One example is when an operating system implicitly allows = commands (I/O) to be reordered within a device driver stack, or have I/O = inserted between existing commands.  Therefore, it is quite = possible and even likely that a complex host would not send a GESN event = immediately following such a command and therefore never get the Device = Busy event. Before = discussing case = C at length, I must first = quote from MMC3r1.0g: 
;This = type of event is usable in two environments. The first is in a queued = environment. The GET 

commands or = in the immediate mode while commands are being executed. The second = environment is 
where = immediate commands and deferred writing are performed; this command may = be issued in the 
immediate = mode to obtain status. If a normal command is issued while the device is = busy, this command 
cannot be = issued until the normal command completes. Therefore, if queuing is not = used, the GET 
The specific = example of the write/read = commands is not a good example Instead, let = us consider case = C for another type of = command that takes an abnormally long time to complete (Format Unit, = Blank, Close Track/Session, etc., always considered with = IMMED=3D1).  In these cases, one can read the above MMC3 section as = stating that any GESN Device Busy request received by the LU shall = report the time from the receipt of the GESN command until the LU will = be able to handle additional commands.  While Katata-san describes = this as ;progress;, the real information contained in the = event is only the amount = of time until the LU is ready to process additional = commandsFrom here, I = think there are two possible paths that devices can follow.  The = first is, when such a long command is executing, that the LU reports a = zero value, as commands will be failed with 2/4/7 or 2/4/8 as = necessary.  In such a case, the Device Busy events are meaningless, = so let us not consider this as a correct solutiuon.  The second = path is that the LU reports the approximate time to the completion of = the long immediate command.  In this case, the host can use this = information.  In fact, with proper driver software, all drivers and = software can be simultaneously informed of the time until the LU is no = longer busy.  (This is what the MMCTest provided by Microsoft's = WHQL has been using during BLANK, FORMAT UNIT, and CLOSE SESSION/TRACK = command testing for some time.) Comments and = questions are welcome. 
Comments and = New">. 

From: = owner-mtfuji5 at avc-pioneer.com [] On Behalf Of Kenji = Tokumitsu 
Sent: = Saturday, November 01, 2003 12:09 AM 
To: = twg3 at ml.cds21solutions.org; T10 at t10.org 
Cc: = mtfuji5 at avc-pioneer.com 
Subject: = RE: Progress Indication function in Device Busy Event#2 Hello = all, The = followings are my comments. 1. Progress = indication 
 In my = understanding, the host cannot know the remaining time directly = from 
the = drive. 
 Host = can know a progress indication by percent. 

remaining = time....;.  Is = there any problem in such a remainig time estimation method = ? 
 I = cannot understand what is the problem. 
 If = someone says ;The problem is that the host cannot estimate the = accurate 
remaining = time.;, 
 I say = ;The drive does not know the accurate remaining = time.;. 
 So, I = think the current esimation method has no problem. 
 And I = think the current estimation method is easy way for host because = host 
can = indicate both 

2. Time = field of Device Busy Event 
 In my = understanding, Time field of Device Busy Event of GESN is to = report 
the = expanded working time for not becoming a timeout. 
 The = remaining processing time is not reported. 
 If = misunderstanding is produced in the current description, we = should 
change = description so that misunderstanding may not occur. Best = Regards, Kenji = Tokumitsu 
Hitachi-LG = Data Storage, Inc. From: = keiji_katata at post.pioneer.co.jp 
] 
Sent: = Friday, October 31, 2003 7:21 PM 
To: = T10 at t10.org 
Cc: = mtfuji5 at avc-pioneer.com; twg3 at ml.cds21solutions.org 
Subject: = Progress Indication function in Device Busy Event#2 

Hello = all, I put = CONSIDERATION.DOC in . 
I correct = the file name and add a section ;2.5 Event lost possibility = of 
Please check = my consideration and send me your comment. Best = regards, Keiji = Katata 
PIONEER = CORP. 





------=_NextPart_001_003E_01C3A1DF.118F78A0--

------=_NextPart_000_003D_01C3A1DF.118F78A0
Content-Type: application/x-pkcs7-signature;
	name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
	filename="smime.p7s"

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIe3jCCA7Ew
ggKZoAMCAQICEGLjZmVSIbeyRuVfQYoWnmIwDQYJKoZIhvcNAQEFBQAwTDELMAkGA1UEBhMCVVMx
EjAQBgNVBAoTCU1pY3Jvc29mdDEOMAwGA1UECxMFTnRkZXYxGTAXBgNVBAMTEE5UREVWIFNBIFJv
b3QgQ0EwHhcNMDIwODA3MDM0NTAyWhcNMDcwODA3MDM1NTAyWjBMMQswCQYDVQQGEwJVUzESMBAG
A1UEChMJTWljcm9zb2Z0MQ4wDAYDVQQLEwVOdGRldjEZMBcGA1UEAxMQTlRERVYgU0EgUm9vdCBD
QTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAOoI+NpQ4wnW1e11kPkhTnigAO0ked3R
JGftlHdGD3DPOwNAkTRzTtSIQTYZkTx+Asu+aoqsru6ed6W/Mxhd7+DxQ2E6nXFvPd7WnSMqEBrA
ITOWcEpSZaS2afWL7up5R7w6PZl8+lheotfJVMdUgDtBvgBC8xTs7PD+zT09iZ4PchILTK0DdKXU
J163rordZSG0cmeCV+pz1/EtBtw6uD8tLsDlIcNWQnph4McYjmNf6jdtuzuwr++CGHi5SEAhHLl0
WjtwzAFltSfRmj2VcljijzpTPEj0lHnXH/G49ohh24NexdzQ0KHjajkM36rIfJplmACDkzmIvl6S
jkyzJW0CAwEAAaOBjjCBizATBgkrBgEEAYI3FAIEBh4EAEMAQTALBgNVHQ8EBAMCAUYwDwYDVR0T
AQH/BAUwAwEB/zAdBgNVHQ4EFgQUiMnNnJw6IoDq5C3aFUcv9fvEvJswEgYJKwYBBAGCNxUBBAUC
AwEAATAjBgkrBgEEAYI3FQIEFgQUnpC7JiTk2txjEbgYLa+tOVaBZlEwDQYJKoZIhvcNAQEFBQAD
ggEBAFhv2fkYKXwaad2xA9h+RjyS8twwPfcAuPRD+W7kvsvBtPeoI4cpMU+f12+SH1WfdhNErRYs
I2Whc+Xlkqm6KLZtUG52qNsHI5aRB2zHVYXLFdFnSZ0xFOsu9y11fh/6Yv3SS7etGrLVtOdzfeOL
xzosK8ZbdBh/wF1b/jB/orp4bgXqsGqQyXGLanR29TLLT2QZjzrt8k9tMM1u+vjQ1tHNEK7qfm4D
plgZUu4wK/QZLwCYoz4u29mQSJ6TWC0VoFQeZu2cv2jtIikzYR/HI9PNJv5AErQ63RJOLy45GosR
S14poZyAoFv9233bFpHXnXz/oeMnW1Rwr5p4JBxsFLEwggWSMIIFUqADAgECAgoppSGSAAUAAAIg
MAkGByqGSM44BAMwYTELMAkGA1UEBhMCVVMxEjAQBgNVBAoTCU1pY3Jvc29mdDEOMAwGA1UECxMF
TnRkZXYxLjAsBgNVBAMTJU5UREVWIEludGVybWVkaWF0ZSBTdWJvcmRpbmF0ZSBXaGljYTIwHhcN
MDIxMDEwMjA0MzA3WhcNMDQxMDEwMjA1MzA3WjBLMQswCQYDVQQGEwJVUzESMBAGA1UEChMJTWlj
cm9zb2Z0MQ4wDAYDVQQLEwVOdGRldjEYMBYGA1UEAxMPTlRERVYgSVNTVUUzIENBMIGfMA0GCSqG
SIb3DQEBAQUAA4GNADCBiQKBgQCslBWXY0NTtIV2J0MY5hQTlVtFlPH3K27ZVXbdGUMe0szXI/jh
rktkRDINZX0v6ej3CWL9mSvqqeVfYUJ4RDcuNjjx1tBibQ5Tk4ujVXIiXdJwKTBiu3YqDhv8ajoj
ZgASrQnAOz+qNGt3EP1Sn0YaNxjPvpy7yLFDd3O7QjxngQIDAQABo4IDwDCCA7wwDwYDVR0TAQH/
BAUwAwEB/zAdBgNVHQ4EFgQUi9HNYfHpr468kdBA6im/5i6FQFcwCwYDVR0PBAQDAgGGMBIGCSsG
AQQBgjcVAQQFAgMCAAMwIwYJKwYBBAGCNxUCBBYEFG63AnsLfqwCcPqopI+9FMOWUqPPMBEGA1Ud
IAQKMAgwBgYEVR0gADAZBgkrBgEEAYI3FAIEDB4KAFMAdQBiAEMAQTAfBgNVHSMEGDAWgBTivgNw
1Ysg0kFEaq/myHdxWiUAHzCCAWkGA1UdHwSCAWAwggFcMIIBWKCCAVSgggFQhoHnbGRhcDovLy9D
Tj1OVERFViUyMEludGVybWVkaWF0ZSUyMFN1Ym9yZGluYXRlJTIwV2hpY2EyKDQpLENOPXdoaWNh
MixDTj1DRFAsQ049UHVibGljJTIwS2V5JTIwU2VydmljZXMsQ049U2VydmljZXMsQ049Q29uZmln
dXJhdGlvbixEQz1udGRldixEQz1jb3JwLERDPW1pY3Jvc29mdCxEQz1jb20/Y2VydGlmaWNhdGVS
ZXZvY2F0aW9uTGlzdD9iYXNlP29iamVjdENsYXNzPWNSTERpc3RyaWJ1dGlvblBvaW50hmRodHRw
Oi8vd2hpY2EyLm50ZGV2LmNvcnAubWljcm9zb2Z0LmNvbS9DZXJ0RW5yb2xsL05UREVWJTIwSW50
ZXJtZWRpYXRlJTIwU3Vib3JkaW5hdGUlMjBXaGljYTIoNCkuY3JsMIIBhgYIKwYBBQUHAQEEggF4
MIIBdDCB3QYIKwYBBQUHMAKGgdBsZGFwOi8vL0NOPU5UREVWJTIwSW50ZXJtZWRpYXRlJTIwU3Vi
b3JkaW5hdGUlMjBXaGljYTIsQ049QUlBLENOPVB1YmxpYyUyMEtleSUyMFNlcnZpY2VzLENOPVNl
cnZpY2VzLENOPUNvbmZpZ3VyYXRpb24sREM9bnRkZXYsREM9Y29ycCxEQz1taWNyb3NvZnQsREM9
Y29tP2NBQ2VydGlmaWNhdGU/YmFzZT9vYmplY3RDbGFzcz1jZXJ0aWZpY2F0aW9uQXV0aG9yaXR5
MIGRBggrBgEFBQcwAoaBhGh0dHA6Ly93aGljYTIubnRkZXYuY29ycC5taWNyb3NvZnQuY29tL0Nl
cnRFbnJvbGwvd2hpY2EyLm50ZGV2LmNvcnAubWljcm9zb2Z0LmNvbV9OVERFViUyMEludGVybWVk
aWF0ZSUyMFN1Ym9yZGluYXRlJTIwV2hpY2EyKDUpLmNydDAJBgcqhkjOOAQDAy8AMCwCFG0a0eml
aHCZ0XREh9+8PT+SuANMAhQLuEXjuaULz1r4zciD4EyvpGjZ7DCCBpMwggX8oAMCAQICCjXOzR8A
AwAt9cwwDQYJKoZIhvcNAQEFBQAwSzELMAkGA1UEBhMCVVMxEjAQBgNVBAoTCU1pY3Jvc29mdDEO
MAwGA1UECxMFTnRkZXYxGDAWBgNVBAMTD05UREVWIElTU1VFMyBDQTAeFw0wMzA1MjcyMzUxNDVa
Fw0wNDA1MjYyMzUxNDVaMIGXMRMwEQYKCZImiZPyLGQBGRYDY29tMRkwFwYKCZImiZPyLGQBGRYJ
bWljcm9zb2Z0MRQwEgYKCZImiZPyLGQBGRYEY29ycDEVMBMGCgmSJomT8ixkARkWBW50ZGV2MQww
CgYDVQQLEwNJVEcxDjAMBgNVBAsTBVVzZXJzMRowGAYDVQQDExFIZW5yeSBHYWJyeWplbHNraTCB
nzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEApDw0/Y2NxREP+Jq9GI+qCHJEoX+oYJ7x0u4ENHaj
CbJ5BbcdIO8IcZJ17OirUUAQQMLiLZKboZCWB4+uG+ee23iJn1QzAfQaacJzgSKqlE0T98EAdc7f
uY7RCoKG2EsjPa3MZWLoxlEH6Z12O+LRwCTGbLBQBGIEYeN50T1m+dECAwEAAaOCBC8wggQrMAsG
A1UdDwQEAwIHgDAdBgNVHQ4EFgQU73Wh7Ne6dK4H26qra0rzcTA3N5wwPgYJKwYBBAGCNxUHBDEw
LwYnKwYBBAGCNxUIjeDRiU6E15zDB4amhvscj9O/phWCv5z2fIbe5oBUAgF4AgEBMB8GA1UdIwQY
MBaAFIvRzWHx6a+OvJHQQOopv+YuhUBXMIIBiAYDVR0fBIIBfzCCAXswggF3oIIBc6CCAW+Ggc9s
ZGFwOi8vL0NOPU5UREVWJTIwSVNTVUUzJTIwQ0EoMiksQ049V0hJQ0EzLENOPUNEUCxDTj1QdWJs
aWMlMjBLZXklMjBTZXJ2aWNlcyxDTj1TZXJ2aWNlcyxDTj1Db25maWd1cmF0aW9uLERDPW50ZGV2
LERDPWNvcnAsREM9bWljcm9zb2Z0LERDPWNvbT9jZXJ0aWZpY2F0ZVJldm9jYXRpb25MaXN0P2Jh
c2U/b2JqZWN0Q2xhc3M9Y1JMRGlzdHJpYnV0aW9uUG9pbnSGTWh0dHA6Ly93aGljYXdlYi5udGRl
di5jb3JwLm1pY3Jvc29mdC5jb20vTlRERVZDUkxzL05UREVWJTIwSVNTVUUzJTIwQ0EoMikuY3Js
hkxodHRwOi8vd2hpY2EzLm50ZGV2LmNvcnAubWljcm9zb2Z0LmNvbS9DZXJ0RW5yb2xsL05UREVW
JTIwSVNTVUUzJTIwQ0EoMikuY3JsMIIBVAYIKwYBBQUHAQEEggFGMIIBQjCBxQYIKwYBBQUHMAKG
gbhsZGFwOi8vL0NOPU5UREVWJTIwSVNTVUUzJTIwQ0EsQ049QUlBLENOPVB1YmxpYyUyMEtleSUy
MFNlcnZpY2VzLENOPVNlcnZpY2VzLENOPUNvbmZpZ3VyYXRpb24sREM9bnRkZXYsREM9Y29ycCxE
Qz1taWNyb3NvZnQsREM9Y29tP2NBQ2VydGlmaWNhdGU/YmFzZT9vYmplY3RDbGFzcz1jZXJ0aWZp
Y2F0aW9uQXV0aG9yaXR5MHgGCCsGAQUFBzAChmxodHRwOi8vd2hpY2EzLm50ZGV2LmNvcnAubWlj
cm9zb2Z0LmNvbS9DZXJ0RW5yb2xsL1dISUNBMy5udGRldi5jb3JwLm1pY3Jvc29mdC5jb21fTlRE
RVYlMjBJU1NVRTMlMjBDQSgzKS5jcnQwEwYDVR0lBAwwCgYIKwYBBQUHAwQwLQYDVR0gBCYwJDAi
BiArBgEEAYI3FQiN4NGJToTXnMMHhqaG+xyP07+mFQGDETAbBgkrBgEEAYI3FQoEDjAMMAoGCCsG
AQUFBwMEMFcGA1UdEQRQME6gLAYKKwYBBAGCNxQCA6AeDBxoZW5yeWdhYkBudGRldi5taWNyb3Nv
ZnQuY29tgR5oZW5yeWdhYkB3aW5kb3dzLm1pY3Jvc29mdC5jb20wDQYJKoZIhvcNAQEFBQADgYEA
oZngVwmM+HPyxenzFt48CJ4RNlb/ze9TkwjZ1gW19Mz/B4l8EQOg9r1zEI2w4P++vJmNNOKDVqVB
eVxVNWnNB1IlS4WPvB0A38o+K+M8c/QRIrgEiYRpzssIED7LXibov4t7fuESumrCar3nPtrTRC11
qVeQAzmAtYk/r6biIMkwggbZMIIGQqADAgECAgo1ztDoAAMALfXNMA0GCSqGSIb3DQEBBQUAMEsx
CzAJBgNVBAYTAlVTMRIwEAYDVQQKEwlNaWNyb3NvZnQxDjAMBgNVBAsTBU50ZGV2MRgwFgYDVQQD
Ew9OVERFViBJU1NVRTMgQ0EwHhcNMDMwNTI3MjM1MTQ2WhcNMDQwNTI2MjM1MTQ2WjCBxjETMBEG
CgmSJomT8ixkARkWA2NvbTEZMBcGCgmSJomT8ixkARkWCW1pY3Jvc29mdDEUMBIGCgmSJomT8ixk
ARkWBGNvcnAxFTATBgoJkiaJk/IsZAEZFgVudGRldjEMMAoGA1UECxMDSVRHMQ4wDAYDVQQLEwVV
c2VyczEaMBgGA1UEAxMRSGVucnkgR2FicnlqZWxza2kxLTArBgkqhkiG9w0BCQEWHmhlbnJ5Z2Fi
QHdpbmRvd3MubWljcm9zb2Z0LmNvbTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAqga01zJv
LSABhM0uYw6cToJN42MVO6GZLSSKMu/07RxyBKccVUxwBfltmq+ZJd0I8yMIW6aoZAT6i18JrjPf
LDSM3w/Z+GZx8cjjwCdY7gim5M3bAv6BPdMOEihZyvWVASBGHfMbxE2HuWuCpKegxczZnM2uSohg
76wKeUsoA+8CAwEAAaOCBEYwggRCMAsGA1UdDwQEAwIEMDBEBgkqhkiG9w0BCQ8ENzA1MA4GCCqG
SIb3DQMCAgIAgDAOBggqhkiG9w0DBAICAIAwBwYFKw4DAgcwCgYIKoZIhvcNAwcwHQYDVR0OBBYE
FK0Q1TO1Y6qIT1/Gxn/7p7QJ1k0/MD4GCSsGAQQBgjcVBwQxMC8GJysGAQQBgjcVCI3g0YlOhNec
wweGpob7HI/Tv6YVh6e+4gmOsa3xTQIBeAIBATAfBgNVHSMEGDAWgBSL0c1h8emvjryR0EDqKb/m
LoVAVzCCAYgGA1UdHwSCAX8wggF7MIIBd6CCAXOgggFvhoHPbGRhcDovLy9DTj1OVERFViUyMElT
U1VFMyUyMENBKDIpLENOPVdISUNBMyxDTj1DRFAsQ049UHVibGljJTIwS2V5JTIwU2VydmljZXMs
Q049U2VydmljZXMsQ049Q29uZmlndXJhdGlvbixEQz1udGRldixEQz1jb3JwLERDPW1pY3Jvc29m
dCxEQz1jb20/Y2VydGlmaWNhdGVSZXZvY2F0aW9uTGlzdD9iYXNlP29iamVjdENsYXNzPWNSTERp
c3RyaWJ1dGlvblBvaW50hk1odHRwOi8vd2hpY2F3ZWIubnRkZXYuY29ycC5taWNyb3NvZnQuY29t
L05UREVWQ1JMcy9OVERFViUyMElTU1VFMyUyMENBKDIpLmNybIZMaHR0cDovL3doaWNhMy5udGRl
di5jb3JwLm1pY3Jvc29mdC5jb20vQ2VydEVucm9sbC9OVERFViUyMElTU1VFMyUyMENBKDIpLmNy
bDCCAVQGCCsGAQUFBwEBBIIBRjCCAUIwgcUGCCsGAQUFBzAChoG4bGRhcDovLy9DTj1OVERFViUy
MElTU1VFMyUyMENBLENOPUFJQSxDTj1QdWJsaWMlMjBLZXklMjBTZXJ2aWNlcyxDTj1TZXJ2aWNl
cyxDTj1Db25maWd1cmF0aW9uLERDPW50ZGV2LERDPWNvcnAsREM9bWljcm9zb2Z0LERDPWNvbT9j
QUNlcnRpZmljYXRlP2Jhc2U/b2JqZWN0Q2xhc3M9Y2VydGlmaWNhdGlvbkF1dGhvcml0eTB4Bggr
BgEFBQcwAoZsaHR0cDovL3doaWNhMy5udGRldi5jb3JwLm1pY3Jvc29mdC5jb20vQ2VydEVucm9s
bC9XSElDQTMubnRkZXYuY29ycC5taWNyb3NvZnQuY29tX05UREVWJTIwSVNTVUUzJTIwQ0EoMyku
Y3J0MBMGA1UdJQQMMAoGCCsGAQUFBwMEMBsGCSsGAQQBgjcVCgQOMAwwCgYIKwYBBQUHAwQwVwYD
VR0RBFAwTqAsBgorBgEEAYI3FAIDoB4MHGhlbnJ5Z2FiQG50ZGV2Lm1pY3Jvc29mdC5jb22BHmhl
bnJ5Z2FiQHdpbmRvd3MubWljcm9zb2Z0LmNvbTANBgkqhkiG9w0BAQUFAAOBgQA0d0I1vP6vEoPc
/iIwofo/lxWbPQOPOVlnBufGbf4UL6+KR0sU//EyKGAi1KYupQXLm1NLkvbUTtFQNiKQSwnwVYqw
Th45C6tLkYRvhvMds8ogSIojSZWhRpoG0SLcDVoaUYqIiryh/lf3ZczCy8ZwX1WCp+hy2/KBzSk1
EFLJ8TCCCBswggcDoAMCAQICCijG53IAAQAAADUwDQYJKoZIhvcNAQEFBQAwTDELMAkGA1UEBhMC
VVMxEjAQBgNVBAoTCU1pY3Jvc29mdDEOMAwGA1UECxMFTnRkZXYxGTAXBgNVBAMTEE5UREVWIFNB
IFJvb3QgQ0EwHhcNMDIxMDEwMTYzMzAwWhcNMDUxMDEwMTY0MzAwWjBhMQswCQYDVQQGEwJVUzES
MBAGA1UEChMJTWljcm9zb2Z0MQ4wDAYDVQQLEwVOdGRldjEuMCwGA1UEAxMlTlRERVYgSW50ZXJt
ZWRpYXRlIFN1Ym9yZGluYXRlIFdoaWNhMjCCAbcwggErBgcqhkjOOAQBMIIBHgKBgQD6Es97u5iw
ea4ZR+QhOQGpawZejbbLfr2SzT0T4SPAAazbhymFpUeoVnf4pD+SDIA0K+w1KSa63b+Gdk9aST1R
ByMQrmtx01/6Pl1Rk2V3Qb+MfjoRy5rddSnE8vQftLaYN6bCQuJvrWjjWm3fssPxAfQKD5XRnR6B
gQUhjnQC4wIVAJhPlD2ydVrV6RStlMJjOhv86OtDAoGAZsoPfe8UED5wq+CK2salIubF17L0j74p
sDv1BBcScAIlkvDlLp754exndP7HA+WDZFQLG0WBflzYMmFQrGLrAtSx/A76Ds6uB8/JYPSv9pAP
NL9kpK+Ax9RBTNiRtyfR26t+tg5PYvFehwGRAPz/JAffyfnCNS6F5VrX8ObmgpgDgYUAAoGBAKJK
0lYkyELe2RtGLY69hi3HKuW08w7JlHUTkM9aovXm+XDiGGtmF4BOnJmUyCBTi8emz3YG8GUgLDnw
UKH0KCxt7yXkHBrAP74+8M45s5WiJmLARfTmURSpewt6/0y0oR1wU0B6Nes3Ahriwl4ULzrK4yYZ
Sr4b0eXzJjaTiuI5o4IEUzCCBE8wDwYDVR0TAQH/BAUwAwEB/zAdBgNVHQ4EFgQU4r4DcNWLINJB
RGqv5sh3cVolAB8wCwYDVR0PBAQDAgGGMBIGCSsGAQQBgjcVAQQFAgMEAAUwIwYJKwYBBAGCNxUC
BBYEFNZSKDdZIeNtheISai1jbapovGtAMBkGCSsGAQQBgjcUAgQMHgoAUwB1AGIAQwBBMB8GA1Ud
IwQYMBaAFIjJzZycOiKA6uQt2hVHL/X7xLybMIIBmQYDVR0fBIIBkDCCAYwwggGIoIIBhKCCAYCG
gdlsZGFwOi8vL0NOPU5UREVWJTIwU0ElMjBSb290JTIwQ0EoMSksQ049d2hpY2FzYXJvb3RjYSxD
Tj1DRFAsQ049UHVibGljJTIwS2V5JTIwU2VydmljZXMsQ049U2VydmljZXMsQ049Q29uZmlndXJh
dGlvbixEQz1udGRldixEQz1jb3JwLERDPW1pY3Jvc29mdCxEQz1jb20/Y2VydGlmaWNhdGVSZXZv
Y2F0aW9uTGlzdD9iYXNlP29iamVjdENsYXNzPWNSTERpc3RyaWJ1dGlvblBvaW50hlFodHRwOi8v
d2hpY2F3ZWIubnRkZXYuY29ycC5taWNyb3NvZnQuY29tL0NlcnRFbnJvbGwvTlRERVYlMjBTQSUy
MFJvb3QlMjBDQSgxKS5jcmyGT2h0dHA6Ly93aGljYTMubnRkZXYuY29ycC5taWNyb3NvZnQuY29t
L0NlcnRFbnJvbGwvTlRERVYlMjBTQSUyMFJvb3QlMjBDQSgxKS5jcmwwggHpBggrBgEFBQcBAQSC
AdswggHXMIHIBggrBgEFBQcwAoaBu2xkYXA6Ly8vQ049TlRERVYlMjBTQSUyMFJvb3QlMjBDQSxD
Tj1BSUEsQ049UHVibGljJTIwS2V5JTIwU2VydmljZXMsQ049U2VydmljZXMsQ049Q29uZmlndXJh
dGlvbixEQz1udGRldixEQz1jb3JwLERDPW1pY3Jvc29mdCxEQz1jb20/Y0FDZXJ0aWZpY2F0ZT9i
YXNlP29iamVjdENsYXNzPWNlcnRpZmljYXRpb25BdXRob3JpdHkwgYQGCCsGAQUFBzAChnhodHRw
Oi8vd2hpY2F3ZWIubnRkZXYuY29ycC5taWNyb3NvZnQuY29tL0NlcnRFbnJvbGwvd2hpY2FzYXJv
b3RjYS5udGRldi5jb3JwLm1pY3Jvc29mdC5jb21fTlRERVYlMjBTQSUyMFJvb3QlMjBDQSgxKS5j
cnQwgYIGCCsGAQUFBzAChnZodHRwOi8vd2hpY2EzLm50ZGV2LmNvcnAubWljcm9zb2Z0LmNvbS9D
ZXJ0RW5yb2xsL3doaWNhc2Fyb290Y2EubnRkZXYuY29ycC5taWNyb3NvZnQuY29tX05UREVWJTIw
U0ElMjBSb290JTIwQ0EoMSkuY3J0MBEGA1UdIAQKMAgwBgYEVR0gADANBgkqhkiG9w0BAQUFAAOC
AQEANMJkJRm8T8IXlhftKI/L9YYwW1dd4JgSv9jstKtjnIAv6PhkpCivuUt+sTsU71SAYqN+z4uo
7SSPFp3jvTjXC0CuTR7lFd4/RRbQjNk5y26vziR7vqyq2CAUWAI598uqFj2mUJx9VIOkGueAAhJd
W6HHygTOm1TZSSpwflkaZ8G+DK10Ip769K2K5WB/me8RAh6Pmifap6e3F18xCxee2PagQW6mOZHo
n1hX1/jcYRaUa4MLUui7XSDziJ0CxtpD6GPEGnx700gY+CLksXWjfndHfZ9Tg5zeCCkYUWIlUqcD
+2qC6ytxXpWI3SxB+10Atqvk+NXbmIDYVpdA5H9ulzGCAp8wggKbAgEBMFkwSzELMAkGA1UEBhMC
VVMxEjAQBgNVBAoTCU1pY3Jvc29mdDEOMAwGA1UECxMFTnRkZXYxGDAWBgNVBAMTD05UREVWIElT
U1VFMyBDQQIKNc7NHwADAC31zDAJBgUrDgMCGgUAoIIBnDAYBgkqhkiG9w0BCQMxCwYJKoZIhvcN
AQcBMBwGCSqGSIb3DQEJBTEPFw0wMzExMDMxNTQ5NTRaMCMGCSqGSIb3DQEJBDEWBBTGcB77zytW
DSP7egHOoeXwHg3TOjBnBgkqhkiG9w0BCQ8xWjBYMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIA
gDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDAHBgUrDgMCGjAKBggqhkiG
9w0CBTBoBgkrBgEEAYI3EAQxWzBZMEsxCzAJBgNVBAYTAlVTMRIwEAYDVQQKEwlNaWNyb3NvZnQx
DjAMBgNVBAsTBU50ZGV2MRgwFgYDVQQDEw9OVERFViBJU1NVRTMgQ0ECCjXO0OgAAwAt9c0wagYL
KoZIhvcNAQkQAgsxW6BZMEsxCzAJBgNVBAYTAlVTMRIwEAYDVQQKEwlNaWNyb3NvZnQxDjAMBgNV
BAsTBU50ZGV2MRgwFgYDVQQDEw9OVERFViBJU1NVRTMgQ0ECCjXO0OgAAwAt9c0wDQYJKoZIhvcN
AQEBBQAEgYCJT3Cw08PX7DHq9B0KwMHAx8Skk5wPq1kVu7Zw/qH84JtNJghG3h8m2gIKklgHSUMI
EgxNP1WwLj35seeaxEb4zOJIakzt9j8XvYi7gu/+TxhOGxOLdBNVyNWAOJfsWfzwRHjKsoCwnDUM
T3UUF63dXAbSo/UMluzo6uDr72qd6AAAAAAAAA==

------=_NextPart_000_003D_01C3A1DF.118F78A0--
*
* For T10 Reflector information, send a message with
* 'info t10' (no quotes) in the message body to majordomo at t10.org




More information about the T10 mailing list