#4257 closed task (complete)

Update client classification requirements and design

Reported by: tomek Owned by: tomek
Priority: high Milestone: Kea1.1
Component: documentation Version: git
Keywords: Cc:
CVSS Scoring: Parent Tickets:
Sensitive: no Defect Severity: N/A
Sub-Project: DHCP Feature Depending on Ticket:
Estimated Difficulty: 0 Add Hours to Ticket: 0
Total Hours: 0 Internal?: no

Description

We decided to finish client classification in 1.1. This ticket covers updating requirements and design documents.

Subtickets

Change History (8)

comment:1 Changed 23 months ago by tomek

  • Owner set to tomek
  • Status changed from new to assigned

comment:2 Changed 22 months ago by tomek

  • Owner changed from tomek to Unassigned
  • Status changed from assigned to reviewing

The proposal is being discussed on kea-dev, moving to reviewing state.

comment:3 Changed 22 months ago by tomek

  • Priority changed from medium to high

comment:4 Changed 22 months ago by sar

  • Owner changed from Unassigned to sar

comment:5 follow-up: Changed 22 months ago by sar

  • Owner changed from sar to tomek

Subnet Class Options

The note at the end of this section has
... print a warning if there is a class specific option and generic option with the same value or even reject the configuration if such case is detected.
I don't believe we can reject the configuration. In one of our standard examples we might want to have most users get some option (say the default router) while users in the better class get the faster router. In this case the subnet would need to have both the class specific option and a non-class option. While we can leave it to the admins to try and sort the options in the proper order it would probably be best if we can do that as part of the parsing step. In this case I'm only thinking of putting all class specific options ahead of all non class options for each subnet.

Accessing Text Representation

Using terse representation and constant length representation are somewhat mutually exclusive. For example if I want to look at the lat byte of an IPv4 address I could access it if we always make the address aaa.bbb.ccc.ddd but have more problems if it could also be a.b.c.d . I think we should probably pick one. I'd vote for terse as complicated items can be done via hooks.

Somewhere, either in this document or possibly in the ticket or the developers guide we should describe how options will be printed. Imagine an option that is <1 byte><1 byte><ipv6 address>. Will this be printed as X Y IP; X, Y, IP; XYIP? Will integers always be decimal? I don't have a strong opinion about the specifics but do think we need to make this consistent over the various options.

Accessing Specifc Fields

I'm not sure what the outcome of this operator is. If I have a v4 option 124: <124><len><enter1><datalen1><data> and I use option[124].enterprise-id am I simply getting the enterprise id <enter1>? or the entire option <enter1><datalen1><data>?

Will this (and the remaining items: constants, relays, sub options) all require .hex or .text (or some other operation) so the command would be option[124].enterprise-id.hex?

comment:6 in reply to: ↑ 5 Changed 22 months ago by tomek

  • Owner changed from tomek to sar

Thanks for the review.

Replying to sar:

Subnet Class Options

The note at the end of this section has
... print a warning if there is a class specific option and generic option with the same value or even reject the configuration if such case is detected.
I don't believe we can reject the configuration. In one of our standard examples we might want to have most users get some option (say the default router) while users in the better class get the faster router. In this case the subnet would need to have both the class specific option and a non-class option. While we can leave it to the admins to try and sort the options in the proper order it would probably be best if we can do that as part of the parsing step. In this case I'm only thinking of putting all class specific options ahead of all non class options for each subnet.

Fair enough. Removed part of existing text and added your suggestion.

Accessing Text Representation

Using terse representation and constant length representation are somewhat mutually exclusive. For example if I want to look at the lat byte of an IPv4 address I could access it if we always make the address aaa.bbb.ccc.ddd but have more problems if it could also be a.b.c.d . I think we should probably pick one. I'd vote for terse as complicated items can be done via hooks.

Agree. Added clarification text explaining that the most terse, human readable format will be used.

Somewhere, either in this document or possibly in the ticket or the developers guide we should describe how options will be printed. Imagine an option that is <1 byte><1 byte><ipv6 address>. Will this be printed as X Y IP; X, Y, IP; XYIP? Will integers always be decimal? I don't have a strong opinion about the specifics but do think we need to make this consistent over the various options.

Let's use spaces. Since X and Y can have arbitrary values, no matter what separator we choose (spaces, comas or something else), there will always be some X value that would clash with it.
I think going with spaces is the most obvious one.

Accessing Specifc Fields

I'm not sure what the outcome of this operator is. If I have a v4 option 124: <124><len><enter1><datalen1><data> and I use option[124].enterprise-id am I simply getting the enterprise id <enter1>? or the entire option <enter1><datalen1><data>?

Yes, just the integer value of the field. There's specific use case for it. We want pick specific vendor, e.g. DOCSIS. The expression will be option[124].enterprise-id == 4491. (4491 is the vendor-id code for CableLabs?).

Will this (and the remaining items: constants, relays, sub options) all require .hex or .text (or some other operation) so the command would be option[124].enterprise-id.hex?

Yes. Right now the option is accessed as option[123].property. There's ticket that accesses relay options. It uses relay[123].property format, which means to get the sub-option 123 of the relay options and use its property (property being .hex, .text or recently implement .exists).

Updated design document as suggested. Are there any outstanding items here or can we close?

comment:7 Changed 22 months ago by sar

  • Owner changed from sar to tomek

I think it is fine and the ticket can be closed.

comment:8 Changed 22 months ago by tomek

  • Resolution set to complete
  • Status changed from reviewing to closed

Closing ticket. Thanks for the review.

Note: See TracTickets for help on using tickets.