Subject: RE: [ipcdn] draft-ietf-ipcdn-bpiplus-mib-10, closure on SAType Ob jects

From: "Wijnen, Bert (Bert)" <[email-masked]>
Date: Thu, 24 Jul 2003 22:47:32 +0200

Inline

> -----Original Message-----
> From: Eduardo Cardona [mailto:[email-masked]]
> Sent: donderdag 24 juli 2003 19:54
> To: Ipcdn (E-mail); Eduardo Cardona; DOCSIS Sec Majordomo List
> Subject: [ipcdn] draft-ietf-ipcdn-bpiplus-mib-10, closure on SAType
> Objects
> 
> 
> Hi all,
> A very similar email was circulated this morning in the ipcdn group. I
> am posting the SEC reflector to hear opinions.
> Thanks
> Eduardo
> 
> The ipcdn group is doing the last updates in BPI plus mib to get the
> draft to the Last Call status and then request and RFc number.
> 
> One of the remaining issues is related to enumerations starting in zero.
> It is not recommended (nor invalid) to have named-values as '0'  but the
> intention is to have the mib very clean in that respect.
> 
Let me explain (again) why we (MIB-doctors) prefer (so we do not mandate)
that enumerations start at 1 instead of zero. The reason is that many
programs are written such that memory allocation for variables results
in an initial value of zero in such a field. So we have seen errors in
implementations where someone just used a non-initized field that conatined
zeroes and so the resulting response to a GET request was/is the zero
value. 

That said, if there are good reasons to start at zero... as I think
you explain below, then that is OK. See more below

> The objects with SA-Type attribute related are docsBpi2CmTEKSAType,
> docsBpi2CmtsTEKSAType and docsBpi2CmtsIpMulticastSAType.
> Issues: 
> enumeration '0' value conflict 
> Vendor-specific representation
> 
> The SA-Type allocates for Vendor-Reserved SA-Type the range 128-255
> is not posible to represent any vendor-reserved SA-Type under the
> current mib syntax
> 
> As I am aware, other than primary, static, dynamic, I do not believe a
> vendor ever will define a new type 
> Will that be a correct assumption? 
> 
> Even though in such case a generic type vendorSpecific(255) would be
> enough to represent that. The final enumeration will be (*): 
> none(0),
> primary(1)
> static(2)
> dynamic(3) 
> vendorSpecific(255)
> 
> Still it does not match the BPKM SA-Type Attibute list 
> indexes which is 
>      primary         - 0
>      static          - 1
>      dynamic         - 2
>      reserved        -   3-128
>      vendor-specific - 128-255
> 
Seems that value 128 can mean two things ??
Is it maybe the following?

>      reserved        -   3-127
>      vendor-specific - 128-255

The range for "vendor-specific" kind of makes me thing that
you should NOT use an enumeration. However, if you do not believe
that such are ever used then using a single value might be 
defendable.

> The truly matching BPKM-mib enumeration would be :
> (**)
> primary(0)
> static(1)
> dynamic(2) 
> vendorSpecific(255)
> none(256)
> 
And so, if that indeed matches up with the SPEC, then that seems
the best assignment to make. In the DESCRIPTION clause explain
that this matches up with the other spec. Potentially
add a REFERENCE clause that points to that spec with which we 
want to be in sync.

Maybe, one could/should add another column, 

  docsBpi2CmTEKSAVendorSpecificType ..
     SYNTAX Integer32 (128..255)
     
And then indicate that if docsBpi2CmTEKSAType has a value of
255, that that means that this docsBpi2CmTEKSAVendorSpecificType
column contains the vendor specific value, and that the meaning of
the values of that ..VendorSpecificType are depending on the specific
vendor.

> An intermedia solution  (***)
> primary(1)
> static(2)
> dynamic(3) 
> vendorSpecific(255)
> none(256)
> 
> Current BPI implementations under draft 05 uses (*) +
> vendorSpecific(255)
> (**) make a shift in all the values - backward compatible problems in
> mibs
> (***) Would be the least intrusive one, keep the values of primary,
> static and dynamic and moves none to 256,
> 
> Eiher case (*) (**) or (***) 'none' is a temprarly value 
> while the SA is
> Authorized/configured. 
> 
So I'd suggest to use my modified (**) above.

Bert
> 
> If (***) is considered the best, I am suggesting a Textual 
> convention to
> explain the values rationale due the conflict of values with the BPKM
> protocol as explained above.  ( other options may need only to change
> quickly the TEXTUAL-CONVENTION 
> Again It will apply to 
>         docsBpi2CmtsIpMulticastSAType
>         docsBpi2CmTEKSAType
>         docsBpi2CmtsTEKSAType
> 
> Note: moved to TEXTUAL-CONVENTION
> "The none(0) encoding must only be used if the SA 
>             type has yet to be determined."
>             
>     
>   DocsBpkmSAType ::= TEXTUAL-CONVENTION 
>             STATUS    current 
>             DESCRIPTION 
>                 "The value of this object is the type of security 
>                  association. The values of the named-numbers are 
>                  associated with the BPKM SA-Type attributes:  
>                  'primary' corresponds to code '0', 'static' 
> to code '1'
>                  'dynamic' to code '2'.
>                  'vendorSpecific' value represents any value in the 
>                  SA-Type attribute range 128 to 255. if used, it is 
>                  recomended the vendor extends the 
> information about the
> 
>                  security association enterprise branch.
>                  'none' value must only be used if the SA type has 
>                  yet to be determined.  
>                 " 
>             REFERENCE
>                  "DOCSIS Baseline Privacy Plus Interface 
> Specification, 
>                  Section 4.2.2.24"
>             SYNTAX    INTEGER {
>                        primary(1),
>                        static(2),
>                        dynamic(3),
>                        vendorSpecific(255),
>                        none(256)
>                       } 
> 
> Objects updates:
>       DocsBpi2CmTEKEntry ::= SEQUENCE { 
>             docsBpi2CmTEKSAId                  Unsigned32, 
>             docsBpi2CmTEKSAType                DocsBpkmSAType,
>             
>             
>        docsBpi2CmTEKSAType OBJECT-TYPE 
>             SYNTAX         DocsBpkmSAType
>             MAX-ACCESS     read-only 
>             STATUS         current 
>             DESCRIPTION 
>                  "The value of this object is the type of security 
>             association." 
>             REFERENCE 
>                  "DOCSIS Baseline Privacy Plus Interface 
> Specification, 
>             Section 2.1.3." 
>             ::= { docsBpi2CmTEKEntry 2 } 
>             
>        DocsBpi2CmtsTEKEntry ::= SEQUENCE { 
>             docsBpi2CmtsTEKSAId                Unsigned32, 
>             docsBpi2CmtsTEKSAType              DocsBpkmSAType, 
>  
>         docsBpi2CmtsTEKSAType    OBJECT-TYPE 
>             SYNTAX         DocsBpkmSAType 
>             MAX-ACCESS     read-only 
>             STATUS         current 
>             DESCRIPTION 
>                  "The value of this object is the type of security 
>             association.  'dynamic' does not apply to CMs running in 
>             BPI mode.  Unicast BPI TEKs must utilize the 'primary'  
>             encoding and multicast BPI TEKs must utilize the 
> 'static'  
>             encoding." 
>             REFERENCE 
>                  "DOCSIS Baseline Privacy Plus Interface 
> Specification, 
>             Section 2.1.3." 
>             ::= { docsBpi2CmtsTEKEntry 2 } 
> 
>        DocsBpi2CmtsIpMulticastMapEntry ::= SEQUENCE { 
>             docsBpi2CmtsIpMulticastIndex            Unsigned32, 
>             docsBpi2CmtsIpMulticastAddressType      InetAddressType, 
>             docsBpi2CmtsIpMulticastAddress          InetAddress, 
>             docsBpi2CmtsIpMulticastMaskType         InetAddressType, 
>             docsBpi2CmtsIpMulticastMask             InetAddress, 
>             docsBpi2CmtsIpMulticastSAId             Integer32, 
>             docsBpi2CmtsIpMulticastSAType           DocsBpkmSAType, 
> 
>        docsBpi2CmtsIpMulticastSAType OBJECT-TYPE 
>             SYNTAX         DocsBpkmSAType
>             MAX-ACCESS     read-create 
>             STATUS         current 
>             DESCRIPTION 
>                  "The value of this object is the type of security 
>             association.  'dynamic' doess not apply to CMs running in 
>             BPI mode.  Unicast BPI TEKs must utilize the 'primary'  
>             encoding and multicast BPI TEKs must utilize the 'static' 
>             encoding." 
>             REFERENCE 
>                  "DOCSIS Baseline Privacy Plus Interface 
> Specification, 
>             Section 2.1.3." 
>             ::= { docsBpi2CmtsIpMulticastMapEntry 7 } 
> 
> 
> _______________________________________________
> IPCDN mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/ipcdn
> 

_______________________________________________
IPCDN mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ipcdn