[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

3GPP Go-PIB



Louis/Kwok,

I really do not have time to check the 3gpp GO PIB in all
details. But I did a quick check of the version you did send 
to me on Aug 14th.

- I have already reported that the REVISION clause is
  invalid syntax. It needs a timespamp according to SPPI
  (RFC3159) and any text needs to go in a DESCRIPTION clasue.

- We did our very very best to get the framework and diffserv
  PIBs approved in the IETF, so that 3GPP could re-use.
  
  However in the 3gpp GO PIB I see:

  Go3gppIpFilterEntry ::= SEQUENCE { 
           go3gppIpFilterAddrType         InetAddressType, 
           go3gppIpFilterDstAddr          InetAddress,  
           go3gppIpFilterDstPrefixLength  InetAddressPrefixLength, 
           go3gppIpFilterSrcAddr          InetAddress,  
           go3gppIpFilterSrcPrefixLength  InetAddressPrefixLength, 
           go3gppIpFilterProtocol         Integer32, 
           go3gppIpFilterDstL4PortMin     InetPortNumber, 
           go3gppIpFilterDstL4PortMax     InetPortNumber, 
           go3gppIpFilterSrcL4PortMin     InetPortNumber, 
           go3gppIpFilterSrcL4PortMax     InetPortNumber 
   } 

   which is not exactly the same as the one in the framework PIB
   but comes VERY VERY close. This does not seem the correct 
   approach to me. HHHre is the framework PIB version:


   FrwkIpFilterEntry ::= SEQUENCE { 
           frwkIpFilterAddrType         InetAddressType, 
           frwkIpFilterDstAddr          InetAddress,  
           frwkIpFilterDstPrefixLength  InetAddressPrefixLength, 
           frwkIpFilterSrcAddr          InetAddress,  
           frwkIpFilterSrcPrefixLength  InetAddressPrefixLength, 
           frwkIpFilterDscp             DscpOrAny, 
           frwkIpFilterFlowId           Unsigned32, 
           frwkIpFilterProtocol         Unsigned32, 
           frwkIpFilterDstL4PortMin     InetPortNumber, 
           frwkIpFilterDstL4PortMax     InetPortNumber, 
           frwkIpFilterSrcL4PortMin     InetPortNumber, 
           frwkIpFilterSrcL4PortMax     InetPortNumber 
   } 
    
   Can you explain/justify why you are not reusing the filters from
   the framework PIB. 

   Let me also point out that your go3gppIpFilterProtocol (Integer32)
   is repeating the problem that we finally got fixed in the 
   frwkIpFilterProtocol (Unsigned32)

- I also think that your references to [INETADDR] in your PIB
  should be done with a REFERENCE clause, as they are done in
  the framework-pib. 

- I guess I could ask the same about the baseFilterTable, but then 
  the one in your go3gppPib seems empty as far as I can tell.

- your 
    go3gppRprtGPRSChrgInfoEntry ::= SEQUENCE { 
           go3gppRprtGPRSChrgInfoPrid       InstanceId,
           go3gppRprtGPRSChrgInfoGGSNAddr   InetAddress,
           go3gppRprtGPRSChrgInfoGCID       OCTET STRING }   

  is using an InetAddress type without an acompanying InetAddressType
  which is required as per the INET-ADDRESS-MIB from which you import
  the InetAddress TC. Without an associated InetAddressType, there
  is no way to know the format of the InetAddress attribute!

- I am kind of surprised that your PIB seems to require far less
  GROUPs to be supported from the FRAMEWORK PIB as has been
  delcared MANDATORY in the framework PIB... I guess I will 
  never understand... 

Note that I did not do a SYNTAX compile check.

Hope this helps you improve, and hope that you either have a very
good justifcation for not re-using the filtertable from 
framework PIB or other wise change your pib to actually do 
reuse that part of the framework PIB.

Bert 

> -----Original Message-----
> From: Louis-Nicolas Hamer [mailto:nhamer@nortelnetworks.com]
> Sent: vrijdag 23 augustus 2002 22:29
> To: 'Wijnen, Bert (Bert)'
> Cc: Stephen Hayes (E-mail)
> Subject: RE: COPS Client-Type assignment 0x8009 (Namer)
> 
> 
> Bert,
>  
> Right. That is beyond my control...MCC is suppose to take 
> care of the assignements under the 3GPP entreprise branch...
> no document exist on this matter for me to consult...they 
> should tell me if my proposition is OK or not. So I will ask
> to delay approval of this document until the next meeting - 
> hopefully we can sort this all out.
>  
> see below for more comments.
>  
> cheers,
>  
>  
> l-n
> 
> Louis-Nicolas Hamer 
> -----Original Message-----
> From: Wijnen, Bert (Bert) [mailto:bwijnen@lucent.com]
> Sent: Friday, August 23, 2002 2:01 PM
> To: Hamer, Louis-Nicolas [WDLN2:AN22:EXCH]
> Cc: Stephen Hayes (E-mail)
> Subject: RE: COPS Client-Type assignment 0x8009 (Namer)
> 
> 
>  You have: 
>      ::= { 1.3.6.1.4.1.10415.1 } -go3gpp PIB branch under the   
>                                                   --3GPP 
> (10415) enterprise branch
> I can hardly believe that there are no other assignment 
> sunder the 3GPP branch yet?
> Why else would the branch have been requested quite a while 
> ago (we are now at
>  enterprise OID 14495 )... 
> It is all within 3GPP tree, so it is 3GPP control... and I 
> may be totally wrong...
> But it feels as if it potentially re-uses some other assignment.
>  
> Just to make sure you did the  proper checks within 3GPP (or the with
> the cisco guy who has his name attached to teh 3GPP tree branch).
> By the way, a
>            REVISION "Use Version Number of 3GPP TS 29.207"
> is syntactically incorrect also. It should be something like
>            REVISION "200205152200Z" 
>            DESCRIPTION    "Initial version as published in  
> 3GPP TS 29.207" 
> [[LNH]] 3GPP procedures require that you show changes to the 
> last official version of the specs.
> The section you quote are from this last version...since 
> then, that section has been modified appropriatly...see
> the pib I sent you the other day. 
>  
> I would strongly recommend that you get your final PIB syntax 
> checked by a tool like
> the one Ravi at Intel uses.
> Yes, we did run it thru the compiler.
> Thanks,
> Bert 
> -----Original Message-----
> From: Louis-Nicolas Hamer [mailto:nhamer@NORTELNETWORKS.COM]
> Sent: vrijdag 23 augustus 2002 18:50
> To: 3GPP_TSG_CN_WG3@LIST.ETSI.FR
> Subject: FW: COPS Client-Type assignment 0x8009 (Namer)
> 
> 
> All, 
> Please see below. IANA has assigned us a COPS Client-type. 
> Since the submission deadline was yesterday for this item, I 
> guess we will have to wait 
> for the next CN3 meeting to approve the CR (unless we can 
> make an exception in this case since 
> this is a very minor change - What is the 
> chairman's/delegates view on this?). 
> The proposed CR is attached to this email. 
> Cheers, 
> L-N 
> 
> 
> -----Original Message----- 
> From: IANA [mailto:iana@icann.org] 
> Sent: Thursday, August 22, 2002 1:43 PM 
> To: Hamer, Louis-Nicolas [WDLN2:AN22:EXCH] 
> Subject: COPS Client-Type assignment 0x8009 (Namer) 
> 
> 
> Dear Louis-Nicolas, 
> The IANA has assigned the following COPS Client-Type: 
> 0x8009  COPS usage for 3GPP GO interface   [3GPP T.S. 29.207 
> - Release 5] 
> [3GPP T.S. 29.207 - Release 5]  
>            ftp://ftp.3gpp.org/specs/Specs/archive/29_series/29.207/ 
> If there is any updates to the reference (new version), please let 
> us know so we can correct the webpage. 
> Please see: 
> <http://www.iana.org/assignments/cops-parameters> 
> Please let us know if you have any questions. 
> Thank you, 
> Michelle S. Cotton 
> IANA Administrator 
> *************************************************************** 
> Internet Assigned Numbers Authority (IANA) 
> 4676 Admiralty Way, Suite 330 
> Marina del Rey, California 90292 
> Voice: (310) 823-9358 
> FAX:   (310) 823-8649 
> email: iana@iana.org 
> *************************************************************** 
>