Bert,
The Go PIB is considered "functionaly frozen", but small corrections
and improvements are still bound to show up. I will write the appropriate CRs to address your comments.
Maybe in the future, sending you comments to the 3GPP CN3 mailing list would be helpfull. CN3 drives the
Go PIB by consensus - I am just a participant - and thus cannot make changes without proper approval of the WG.
Thanks.
please see below.
> -----Original Message-----
> From: Wijnen, Bert (Bert) [mailto:bwijnen@lucent.com]
> Sent: Friday, August 23, 2002 5:44 PM
> To: Hamer, Louis-Nicolas [WDLN2:AN22:EXCH]; Chan, Kwok-Ho
> [BL60:470:EXCH]; Rap-wg (E-mail)
> Cc: Stephen Hayes (E-mail); Scott Bradner (E-mail); Allison Mankin
> (E-mail); Thomas Narten (E-mail); Randy Bush (E-mail)
> Subject: 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.
Yes, thanks...will update this.
>
> - 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.
We, Nortel, tried very hard to reuse the filters from the framework PIB, but other companies objected
to this. So I guess you should ask them to justify themsleves. Remember, 3GPP works by consensus between
all attending companies.
>
> 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.
Will do.
>
> - 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.
Same as other comment - we wanted to import, others did not...I will let them explain why.
It might be more than usefull if you clearly stated this on the CN3 mailing list. Maybe you could
help us convince others.
>
> - 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!
Good catch...will correct. The Go PIB is considered functionaly frozen, but small corrections
and improvements are still bound to show up. I will write the appropriate CR.
>
> - 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.
Again, sorry I can't help. Please consult prior contributions...you will clealy see we advocated this while others did not.
>
> 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
> > ***************************************************************
> >
>