stds-802-16: TG1 COMMENTS

[Ken Stanwood <ken@ensemblecom.com>]

[Submitter's Last Name] 
Hameed

[Submitter's First Name]
Farooq

[Membership Status: (M)ember; (O)bserver; (N)either]
N

[Starting Page #]
206

[Starting Line #]
26

[(T)echnical for Content-Related Material; (E)ditorial for typos, grammar,
etc.;
(G)eneral to identify a problem but not a solution; (TBD) for a
comment on a section marked "TBD"]
E

[Detailed Description of Proposed Insertion, Deletion, Change]
Instead of "single packet date" should be "single packet data".

[Reason for Edit]
Typo.





[Submitter's Last Name] 
Hameed

[Submitter's First Name]
Farooq

[Membership Status: (M)ember; (O)bserver; (N)either]
N

[Starting Page #]
208

[Starting Line #]
39

[(T)echnical for Content-Related Material; (E)ditorial for typos, grammar,
etc.;
(G)eneral to identify a problem but not a solution; (TBD) for a
comment on a section marked "TBD"]
E

[Detailed Description of Proposed Insertion, Deletion, Change]
Remove 'the SS's RSA public key'.

[Reason for Edit]
Clarity. Text implies that the key is duplicated in the message, since it is
already part of the X.509 certificate. This is inconsistent with the 
description of the "Authorization Request" message, section 2.16.2.1.1 
on page 230, line 60.





[Submitter's Last Name] 
Hameed

[Submitter's First Name]
Farooq

[Membership Status: (M)ember; (O)bserver; (N)either]
N

[Starting Page #]
211
[Starting Line #]
26

[(T)echnical for Content-Related Material; (E)ditorial for typos, grammar,
etc.;
(G)eneral to identify a problem but not a solution; (TBD) for a
comment on a section marked "TBD"]
E

[Detailed Description of Proposed Insertion, Deletion, Change]
Change "While the Authorization Reply may identify...." to
"must identify" or "shall identify".

[Reason for Edit]
Clarity. Current text implies that the BS may not identify static SA's whose
SAID matched the requesting SS's basic CID. Most likely, the intent here was

to say that the message will identify all static SA' whose SAID matches the
requesting SS's basic CID and this number may be 0.







[Submitter's Last Name] 
Hameed

[Submitter's First Name]
Farooq

[Membership Status: (M)ember; (O)bserver; (N)either]
N

[Starting Page #]
217

[Starting Line #]
53

[(T)echnical for Content-Related Material; (E)ditorial for typos, grammar,
etc.;
(G)eneral to identify a problem but not a solution; (TBD) for a
comment on a section marked "TBD"]
T

[Detailed Description of Proposed Insertion, Deletion, Change]
Define some means for the SS to identify permanent errors

[Reason for Edit]
The SS must be able to identify which errors are of a permanent nature.
Currently the spec. is unclear on how the list of permanent errors
configured on the BS is transferred to the SS. Some possible ways are
1) Include an explicit field in the Authorization Reject Message.
2) Provide the list in tftp config file.
Of the above the option (1) is the most robust. It correctly deals
with the situation where the "permanent error list" on the BS changes
dynamically, which option (2) does not deal with.






[Submitter's Last Name] 
Hameed

[Submitter's First Name]
Farooq

[Membership Status: (M)ember; (O)bserver; (N)either]
N

[Starting Page #]
218

[Starting Line #]
1

[(T)echnical for Content-Related Material; (E)ditorial for typos, grammar,
etc.;
(G)eneral to identify a problem but not a solution; (TBD) for a
comment on a section marked "TBD"]
T

[Detailed Description of Proposed Insertion, Deletion, Change]
Change defintion of silent state. Unauthorized SS's should not be
allowed to transmit, even to respond to management requests. 

[Reason for Edit]
Having an authorized SS sending traps or sending other management traffic
is undesirable. This means that the MAC is obligated to honor bandwidth
requests from unauthorized SS's. This deny's service to authorized users.
If management of an SS is required, it should be authorized
and then managed. The sequence of actions that must occur is as follows:
- The BS is informed that the SS is authorized.
- An SNMP message is sent to the SS indicating that it should attempt
  authorization again. Note that this may be done over some broadcast
  channel that the SS listens to while in the silent state.
- The SS sends an Auth Request to the BS and enters authorized state
- Management of SS can proceed at this time.





[Submitter's Last Name] 
Hameed

[Submitter's First Name]
Farooq

[Membership Status: (M)ember; (O)bserver; (N)either]
N

[Starting Page #]
231

[Starting Line #]
56

[(T)echnical for Content-Related Material; (E)ditorial for typos, grammar,
etc.;
(G)eneral to identify a problem but not a solution; (TBD) for a
comment on a section marked "TBD"]
T

[Detailed Description of Proposed Insertion, Deletion, Change]
Change format of 'Authorization Reject' message. Remove 'Error Code'
field.

[Reason for Edit]
Security requires providing as little information as possible 
about authorization failures. An example is remote logging in to a 
workstation; if the login fails the response simply states that it
failed and not whether the password or the login name was improper.
We should follow a similar model; state whether authorization was
successful or it failed and whether the failure was of a permanent
nature. Additional information about the failure may be logged by 
BS and can be used for debugging during installation. However, this
information should not be provided to the SS.






[Submitter's Last Name] 
Hameed

[Submitter's First Name]
Farooq

[Membership Status: (M)ember; (O)bserver; (N)either]
N

[Starting Page #]
243

[Starting Line #]
10

[(T)echnical for Content-Related Material; (E)ditorial for typos, grammar,
etc.;
(G)eneral to identify a problem but not a solution; (TBD) for a
comment on a section marked "TBD"]
T

[Detailed Description of Proposed Insertion, Deletion, Change]
Change
"This attribute contains either a 96 or a 128 bit quantity containing the
authorization Key RSA-encrypted with the SS's 1024-bit RSA public key"
to
"This attribute contains either a 96 or a 128 bit quantity containing the
authorization Key RSA-encrypted with the SS's RSA public key"

[Reason for Edit]
A single length for the SS's RSA key should not be specified. A minimum
length should be specified elsewhere in the document. The miminum length
may be placed under administrative control.






[Submitter's Last Name] 
Hameed

[Submitter's First Name]
Farooq

[Membership Status: (M)ember; (O)bserver; (N)either]
N

[Starting Page #]
257

[Starting Line #]
38

[(T)echnical for Content-Related Material; (E)ditorial for typos, grammar,
etc.;
(G)eneral to identify a problem but not a solution; (TBD) for a
comment on a section marked "TBD"]
E

[Detailed Description of Proposed Insertion, Deletion, Change]
Change 
"a SS (Customer Premise Equipment) device attached to one of the 
BS's client SS"
to
"Customer Premise Equipment device attached to one of the 
BS's client SS"


[Reason for Edit]
Typo.