Re: [bess] MIBDoc review of draft-ietf-bess-l2l3-vpn-mcast-mib-02.txt

[Glenn Mansfield Keeni <[e-mail]>]

Hi Jeffrey,
 > By "continuously" do you mean every possible value between 0 and 50?
 > With currently defined types, it's not like that; for tunnel types
 > potentially defined in the future, they may take any value (who
 > knows). It may even go beyond 50.
Yes. The doc will be read as a specification by implementors.
The specifications must be as precise as possible. It it varies
continuously between 0 and 50 then the current description is
correct. RFC 6514 sec 5.  PMSI Tunnel Attribute enumerates the
different cases. It appears that the attribute takes a set of
discrete values. I would recommend that the set of discrete values
must be specified and also explained in the description. This will
also be supplemented by the reference clause.
The object definition will look like
   l2L3VpnMcastPmsiTunnelAttributeId OBJECT-TYPE
      SYNTAX        OCTET STRING ( SIZE (0|L1|L2|L3) )
      MAX-ACCESS    not-accessible
      STATUS        current
      DESCRIPTION
          "Different tunnel types will have different sizes for
           this object.
           For tunnel type 'unconfigured', this will be a zero-length  
string.
           For tunnel type 'rsvpP2mp', this will be <explanation of the
           identifier> of length <calculated length of the identifier= L1>
           Etc.
          "
      REFERENCE
          "RFC 6514 sec 5.  PMSI Tunnel Attribute"
      ::= { l2L3VpnMcastPmsiTunnelAttributeEntry 4 }

 > for tunnel types
 > potentially defined in the future, they may take any value (who
 > knows). It may even go beyond 50.
The MIB is anchored to RFC 6514. It does not explicitly or implicitly  
provision for future tunnel types. It explicitly provisions for only
8 tunnel types. I would recommend that we stick
  to that line.

Glenn

On 2016/05/14 1:14, Jeffrey (Zhaohui) Zhang wrote:
> Hi Glenn,
>
> Before I post a new revision, I want to check with you on the following:
>
>>  >  > > 8.3   l2L3VpnMcastPmsiTunnelAttributeId OBJECT-TYPE
>>  >  Depending on the tunnel type, there could be different sizes.
>>  > Future tunnel types could have other sizes that not specified
>>  > today. I was thinking to just give a size
>>  > tPmsiTunnelAttributeId OBJECT-TYPE range so that it is flexible.
>>  > Is that ok?
>> I see that you have changed the size upper limit to 50.
>> If the size varies continuously from 0 to 50 the above description
>> is correct.
>> Please confirm, explain and cite appropriate reference. If the size
>> may change in the future that must be stated too.
>
> By "continuously" do you mean every possible value between 0 and 50? With currently defined types, it's not like that; for tunnel types potentially defined in the future, they may take any value (who knows). It may even go beyond 50.
>
> Given this, what's the best way to proceed?
>
> Thanks.
> Jeffrey
>