Subject: [AAA-WG]: NASREQ-10 comments

From: "Kuntal Chowdhury" <[email-masked]>
Date: Sat, 28 Dec 2002 14:53:56 -0600

Hello,
Here is a list of comments on nasreq-10 draft. The draft seems to be quite
stable. Did not find any major issue.

Regards,
Kuntal

------------------------------------------------------------------------
Description of issue
Submitter name: Kuntal Chowdhury
Submitter email address: [email-masked]
Date first submitted: 12/28/02
Reference:  
Document:  nasreq
Comment type: E 
Priority: 1 
Section: 4.1.3
Rationale/Explanation of issue: 
...This AVP SHOULD be present if the NAS uses the same NAS-Port
   number ranges for different services types concurrently.
Proposal:

...This AVP SHOULD be present if the NAS uses the same NAS-Port
   number ranges for different service types concurrently.
----------------------------------------------------------------

Description of issue
Submitter name: Kuntal Chowdhury
Submitter email address: [email-masked]
Date first submitted: 12/28/02
Reference:  
Document:  nasreq
Comment type: T 
Priority: 1
Section: 4.2.6
Rationale/Explanation of issue: 

      CHAP with MD5       5
         The CHAP response is computed using the procedure described in
         [PPPCHAP].  The CHAP-Response AVP MUST be present in the CHAP-
         Auth AVP.

Comment: We should not talk about CHAP-Response AVP in the CHAP-Algorithm
AVP section. Also according to the ABNF grammar, the CHAP-Response AVP is
not mandatory in CHAP-Auth AVP.

Proposal: Delete the paragraph below CHAP with MD5	5.
-----------------------------------------------------------------

Description of issue
Submitter name: Kuntal Chowdhury
Submitter email address: [email-masked]
Date first submitted: 12/28/02
Reference:  
Document:  nasreq
Comment type: T
Priority: 2 
Section: 4.4
Rationale/Explanation of issue: 
Tunneling AVP is of type Grouped but MAY NOT be encrypted. Whereas CHAP-Auth

AVP MAY be encrypted, but it is of type Grouped as well. In the entire spec
Tunneling AVP is the only one that has "N" in MAY Encr column. Is this an
error
or is there a reason for it? Since almost all of the AVPs have MAY Encr = Y
this column can be replaced by a global declaration ( e.g. may encrypt all
AVPs).
-------------------------------------------------------------------

Description of issue
Submitter name: Kuntal Chowdhury
Submitter email address: [email-masked]
Date first submitted: 12/28/02
Reference:  
Document:  nasreq
Comment type: T 
Priority: 1
Section: 5.8
Rationale/Explanation of issue: 

       Acct-Multi-                   Accounting-     Acct-
      Session-Id     Session-Id     Record-Type     Link-Count
      --------------------------------------------------------
        "...10"        "...10"      START_RECORD        1
        "...10"        "...11"      START_RECORD        2
        "...10"        "...11"      STOP_RECORD         2
        "...10"        "...12"      START_RECORD        3
        "...10"        "...13"      START_RECORD        4
        "...10"        "...12"      STOP_RECORD         4
        "...10"        "...13"      STOP_RECORD         4
        "...10"        "...10"      STOP_RECORD         4

At the fourth step, the Acct-Link-Count should be 2, because at the third
step the link with session-Id ...11 was closed, thus leaving only session-Id
...10 open.
----------------------------------------------------------------

Description of issue
Submitter name: Kuntal Chowdhury
Submitter email address: [email-masked]
Date first submitted: 12/28/02
Reference:  
Document:  nasreq
Comment type: T 
Priority: 1
Section: 6.1.1
Rationale/Explanation of issue: 

      - If a Proxy-Info AVP is present, extract the encoded information,
        otherwise retrieve the information from the local state table.

      - If a Proxy-Info AVP was present in the request, the same AVP
        MUST be added to the response.
      
The Proxy-Info AVP is not supported in RADIUS. Should it be Proxy-State AVP
instead?
-----------------------------------------------------------------

Description of issue
Submitter name: Kuntal Chowdhury
Submitter email address: [email-masked]
Date first submitted: 12/28/02
Reference:  
Document:  nasreq
Comment type: E
Priority: 1
Section: 6.2
Rationale/Explanation of issue: 

   The AVPs defined in this section SHOULD only used for backwards
   compatibility when a Diameter/RADIUS translation function is invoked,
   and are not typically originated by Diameter systems.

Proposal:
   The AVPs defined in this section SHOULD only be used for backward
   compatibility when a Diameter/RADIUS translation function is invoked,
   and are not typically originated by Diameter systems during normal 
   operation.
----------------------------------------------------------------

Description of issue
Submitter name: Kuntal Chowdhury
Submitter email address: [email-masked]
Date first submitted: 12/28/02
Reference:  
Document:  nasreq
Comment type: E/T
Priority: 1
Section: 7.2.1 and 7.2.2
Rationale/Explanation of issue: 
The AVPs that are MUST not be present in a command Request/Answer are still
shown in the table.

Proposal:
Section 7.2.1
State AVP MUST not be present in both ACR and ACA. There is no need to show
it in the table. Delete this entry.

Section 7.2.2:
Same as above: delete Accounting-Input-Packets, Accounting-Output-Packets, 
NAS-Filter-Rule, State entries from the AVP table for these types of 
accounting messages.
-----------------------------------------------------------------

Description of issue
Submitter name: Kuntal Chowdhury
Submitter email address: [email-masked]
Date first submitted: 12/28/02
Reference:  
Document:  nasreq
Comment type: E
Priority: 1
Section: 10
Rationale/Explanation of issue: 

Update reference for CDMA2000 with the latest release of the standard.

[CDMA2000]    3GPP2 "P.S0001-A v3.0", Wireless IP Network Standard, July
              2001.
              http://www.3gpp2.com/Public_html/specs/P.S0001-A_v3.0.pdf
Proposal:

[CDMA2000]    3GPP2 "P.S0001-B", Wireless IP Network Standard, October 
              2002.
              http://www.3gpp2.com/Public_html/specs/P.S0001-B_v1.0.pdf