Subject: [ipcdn] draft-ietf-ipcdn-bpiplus-mib-10, closure on SAType Objects

From: "Eduardo Cardona" <[email-masked]>
Date: Thu, 24 Jul 2003 11:54:10 -0600

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.

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

The truly matching BPKM-mib enumeration would be :
(**)
primary(0)
static(1)
dynamic(2) 
vendorSpecific(255)
none(256)

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. 

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

---

From: "Eduardo Cardona" <[email-masked]>
Date: Thu, 24 Jul 2003 18:17:26 -0600

Bert Thanks for the comments See more inline notes

-----Original Message-----
From: Wijnen, Bert (Bert) [mailto:[email-masked]] 
Sent: Thursday, July 24, 2003 2:48 PM
To: Eduardo Cardona; Ipcdn (E-mail); DOCSIS Sec Majordomo List
Subject: RE: [ipcdn] draft-ietf-ipcdn-bpiplus-mib-10, closure on SAType
Objects

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,

> am posting the SEC reflector to hear opinions. Thanks
> Eduardo
> 
> 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 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

> vendor ever will define a new type Will that be a correct assumption?
> 
> enough to represent that. The final enumeration will be (*): none(0),
> primary(1)
> static(2)
> dynamic(3) 
> vendorSpecific(255)
> 
Seems that value 128 can mean two things ??
Is it maybe the following?

>      reserved        -   3-127

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.

<edo> 
It is very unlikely that with the current BPI protocol implementation a
vendor decide to define another SA Type
The protocol is extensible but I (we) believe is unrealistic that it
will happen, someone in the OSS/SEC can point if I am wrong and such
SA-Types does/will exist.

</edo>

> The truly matching BPKM-mib enumeration would be :
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.

<edo> 
That's true, ( that's why (**) is presented as an option with a '0'
justified) unfortunately there are many many  boxes in the field with
the current enumeration (I know, and unfortunately does not match the
protocol) "primary(1), static(2), dynamic(3)" instead of the ideal
"primary(0), static(1), dynamic(2)"

In my proposed TEXTUAL-CONVENTION we cab switch (***) to (**), etc ...

That's means changes in the logic of the current DOCSIS managements
applications and not being backward compatible with the current
implementations, 

For the broad audience, Do we want/need the Patched mib or should we go
for the clean one (**), MSO input would be appreciated. 

Option (***) and the description in the TEXTUAL-CONVENTION is trying to
: (due a legacy crossed values), That's a PATCH no discussion... 

To indicate primary(1) -> SA-TYPE =0
            static(2)  -> SA-TYPE =1
            dynamic(3) -> SA-TYPE =2
            vendorSpecific(255) -> SA-TYPE 128-255
            none(256)  -> SA-Type Not known yet

Thinking more I won't complain the Mib authors for the initial none(0)
selection in (*) because it matches exactly your description of value
'0' as an implementation problem. The process is as follow:
An entry is created for an SA and after authorization/configuration, the
SAType is known and the SAType object si assigned to 1/2/3.
  
</edo>

> Eiher case (*) (**) or (***) 'none' is a temprarly value
So I'd suggest to use my modified (**) above.
<Edo>
Not a problem, docsBpi2CmTEKSAVendorSpecificType may not provide enough
information since two different implementer may assign value 128 to
their vendor-SA-Type with different meaning. And as explained above the
likehood of this case is very remote, I am not sure if will make sense,
and leave that as extensions/augments in the vendor enterprise subtree
</edo>

Bert

---

From: "Jean-Francois Mule" <[email-masked]>
Date: Fri, 25 Jul 2003 10:01:16 -0600

A couple of thoughts on docsBpi2CmTEKSAType based on the options we
discussed so far.

First, I like option (*) with Bert's proposal to add
docsBpi2CmTEKSAVendorSpecificType
> (*): none(0),
This option has the merit to:
 + address the mib-doctor concerns on enum value 0 and I agree with
Eduardo on the justification.
> The process is as follow: An entry is created for an SA and 
> after authorization/configuration, the SAType is known and 
> the SAType object si assigned to 1/2/3.
 may be we could add some text in the object description to state the
above. 
 + keep compatibility with the current field implementations of the ID
(even though this is valid concern from an IETF prospective, it is a
plus if we can accommodate it)
 + adding vendorSpecific value allows to match the docsis protocol spec

Additional Comments:
 + commnent on value 255 in docsBpi2CmTEKSAType 
> (*): none(0),
                   ^^^
      since value 255 does not necessarily mean
docsBpi2CmTEKSAVendorSpecificType = 255, I would prefer to use a
distinct value for vendor specific types to indicate "go look in
docsBpi2CmTEKSAVendorSpecificType" for the actual value - just so that
we don't have an overlap that could be misinterpreted.
So new proposal is:
> (*): none(0),
> > vendorSpecific(256)

 + comment on docsBpi2CmTEKSAVendorSpecificType
>      SYNTAX Integer32 (128..255)
   one concern is what would be the value returned by an object instance
when docsBpi2CmTEKSAType=0|1|2|3 ? Basically a GET on this when the
value is 0|1|2|3 should not return a value in the range of 128..255.
   so again, I'd propose to add a special value outside the valid range
for VendorSpecificType, something like:
>      SYNTAX Integer32 (128..256)
   and indicate in the description clause that when docsBpi2CmTEKSAType
!= 256, docsBpi2CmTEKSAVendorSpecificType MUST be equal to 256. I picked
256 but anything outside 128..255 would work.

Jean-Francois.

---

From: "Jean-Francois Mule" <[email-masked]>
Date: Fri, 25 Jul 2003 10:08:31 -0600

I meant:
... snip
> This option has the merit to:
...snip
>  + keep compatibility with the current field implementations 
> of the ID (even though this is *not* a valid concern from an IETF 
                                  ^^^^
> prospective, it is a plus if we can accommodate it)  + adding 
> vendorSpecific value allows to match the docsis protocol spec

Jean-Francois.

---

From: "Eduardo Cardona" <[email-masked]>
Date: Fri, 25 Jul 2003 10:38:40 -0600

Jean-Francois, 

I feel confortable with your suggestion, 

I twick The proposed TC ( added some extra tunning ), 

Also for the proposed object docsBpi2CmTEKSAVendorSpecificType.

Although I do not desagree with that and find it not harmful, I do not
see any special added value just indicating a value in 128-255 range
that is meaning less if not associated with a context (CM-CMTS
Vendor/product, etc.) 

Two counter proposals:

See the TC description for recommendations in how to handle that case :
recommended case

Or 

Define the    docsBpi2CmTEKSAVendorSpecificType as
docsBpi2CmTEKSAVendorSpecificTypePtr with RowPointer syntax
With default zerodotZero to point to more detailed and specific
information.

Eduardo

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 and operational 
        considerations: 
        'none' value must only be used if the SA type has yet to be 
        determined, this case may occur due the fact that the 
        security association can be created by several mechanisms 
        and the SA-Type is confirmed until the SA authentication and 
        configuration of the SA is completed . 
        'primary' corresponds to SA-Type attribute 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 in the enterprise sub-tree via the AUGMENTS  clause
        when this TEXTUAL-CONVENTION is used in the syntax of a columnar

        object,  or an indirect reference if this TEXTUAL-CONVENTION is 
        in the syntax of a scalar object"
        REFERENCE
              "DOCSIS Baseline Privacy Plus Interface
        specification, Section 4.2.2.24"
        SYNTAX    INTEGER {
                       none(0),
                       primary(1),
                       static(2),
                       dynamic(3),
                       vendorSpecific(256)
                  }

-----Original Message-----
From: Jean-Francois Mule 
Sent: Friday, July 25, 2003 10:01 AM
To: Eduardo Cardona; Wijnen, Bert (Bert); Ipcdn (E-mail); DOCSIS Sec
Majordomo List; DOCSIS OSS Majordomo List
Subject: RE: [ipcdn] draft-ietf-ipcdn-bpiplus-mib-10, closure on SAType
Objects

 may be we could add some text in the object description to state the
above. 
 + keep compatibility with the current field implementations of the ID
(even though this is valid concern from an IETF prospective, it is a
plus if we can accommodate it)  + adding vendorSpecific value allows to
match the docsis protocol spec

Additional Comments:
                   ^^^
we don't have an overlap that could be misinterpreted. So new proposal

Jean-Francois.