Send kea-dev mailing list submissions to
[email protected]
To subscribe or unsubscribe via the World Wide Web, visit
https://lists.isc.org/mailman/listinfo/kea-dev
or, via email, send a message with subject or body 'help' to
[email protected]
You can reach the person managing the list at
[email protected]
When replying, please edit your Subject line so it is more specific
than "Re: Contents of kea-dev digest..."
Today's Topics:
1. Re: Client classification design (Thomas Markwalder)
2. Re: Client classification design (Marcin Siodelski)
3. Re: Client classification design (Shawn Routhier)
----------------------------------------------------------------------
Message: 1
Date: Wed, 14 Oct 2015 10:44:56 -0400
From: Thomas Markwalder <[email protected]>
To: Tomek Mrugalski <[email protected]>, [email protected]
Subject: Re: [kea-dev] Client classification design
Message-ID: <[email protected]>
Content-Type: text/plain; charset=windows-1252
On 10/13/15 11:31 AM, Tomek Mrugalski wrote:
> Folks,
> I took a first stab at the client classification design. See the
> document here: http://kea.isc.org/wiki/ClientClassificationDesign
>
> For the reference, we have the requirements more or less described here:
> http://kea.isc.org/wiki/ClientClassificationRequirements.
>
> We had some discussions about the syntax, but I did think about it a bit
> more and came up with three alternative proposals. Please comment on
> which one seems to be the best in your opinion (or reject all of them
> and propose a fourth one). I tried to be objective and not push for any
> specific one.
>
> Keep in mind that we're working under very tight schedule here and
> client classification is a broad and complex topic. There's a lot we
> could do, but due to the time constraints, we need to be very selective
> for phase 1 (aka Kea 1.0).
>
> Some parts of the design will likely be moved to the requirements page,
> but I want to keep it in the new doc for now, so you could review it
> more easily as one chunk.
>
> It would be great if you could provide your comments by end of this week
> (Oct. 16th), so we could start an implementation the next week.
>
> Thoughts? Comments? Tomatoes?
>
> Tomek
>
> _______________________________________________
> kea-dev mailing list
> [email protected]
> https://lists.isc.org/mailman/listinfo/kea-dev
We went from Stephen's initial draft of requirements to a design
document? Did
I miss a step of reviewing the requirements? The requirements document
itself,
while containing a wealth of good information, is more of a high level
design
than a set of software requirements. In general, software requirements
describe a list of behaviors that system must provide, expressed as
statements
which can be verified by testing the system.
So which document are we reviewing? We can't review design unless we've
reviewed the requirements. Cart before the horse. Technically, a design
must be reviewed against the requirements driving it in order to ensure
the design fulfills them.
I do acknowledge that a lot of good thought/work has been done by Stephen
and Tomek, don't misunderstand.
I am going through both documents.
Thomas
------------------------------
Message: 2
Date: Wed, 14 Oct 2015 16:53:01 +0200
From: Marcin Siodelski <[email protected]>
To: Thomas Markwalder <[email protected]>, Tomek Mrugalski
<[email protected]>, [email protected]
Subject: Re: [kea-dev] Client classification design
Message-ID: <[email protected]>
Content-Type: text/plain; charset=utf-8
On 14.10.2015 16:44, Thomas Markwalder wrote:
> On 10/13/15 11:31 AM, Tomek Mrugalski wrote:
>> Folks,
>> I took a first stab at the client classification design. See the
>> document here: http://kea.isc.org/wiki/ClientClassificationDesign
>>
>> For the reference, we have the requirements more or less described here:
>> http://kea.isc.org/wiki/ClientClassificationRequirements.
>>
>> We had some discussions about the syntax, but I did think about it a bit
>> more and came up with three alternative proposals. Please comment on
>> which one seems to be the best in your opinion (or reject all of them
>> and propose a fourth one). I tried to be objective and not push for any
>> specific one.
>>
>> Keep in mind that we're working under very tight schedule here and
>> client classification is a broad and complex topic. There's a lot we
>> could do, but due to the time constraints, we need to be very selective
>> for phase 1 (aka Kea 1.0).
>>
>> Some parts of the design will likely be moved to the requirements page,
>> but I want to keep it in the new doc for now, so you could review it
>> more easily as one chunk.
>>
>> It would be great if you could provide your comments by end of this week
>> (Oct. 16th), so we could start an implementation the next week.
>>
>> Thoughts? Comments? Tomatoes?
>>
>> Tomek
>>
>> _______________________________________________
>> kea-dev mailing list
>> [email protected]
>> https://lists.isc.org/mailman/listinfo/kea-dev
> We went from Stephen's initial draft of requirements to a design
> document? Did
> I miss a step of reviewing the requirements? The requirements document
> itself,
> while containing a wealth of good information, is more of a high level
> design
> than a set of software requirements. In general, software requirements
> describe a list of behaviors that system must provide, expressed as
> statements
> which can be verified by testing the system.
>
> So which document are we reviewing? We can't review design unless we've
> reviewed the requirements. Cart before the horse. Technically, a design
> must be reviewed against the requirements driving it in order to ensure
> the design fulfills them.
>
> I do acknowledge that a lot of good thought/work has been done by Stephen
> and Tomek, don't misunderstand.
>
> I am going through both documents.
>
I am with you here. But, I think it is a result of altering the course
in rush and simply lack of time to organize this in a right way.
Marcin
------------------------------
Message: 3
Date: Wed, 14 Oct 2015 20:09:47 -0700
From: Shawn Routhier <[email protected]>
To: Tomek Mrugalski <[email protected]>
Cc: [email protected]
Subject: Re: [kea-dev] Client classification design
Message-ID: <[email protected]>
Content-Type: text/plain; charset=utf-8
> On Oct 13, 2015, at 8:31 AM, Tomek Mrugalski <[email protected]> wrote:
>
> Folks,
> I took a first stab at the client classification design. See the
> document here: http://kea.isc.org/wiki/ClientClassificationDesign
>
> For the reference, we have the requirements more or less described here:
> http://kea.isc.org/wiki/ClientClassificationRequirements.
>
> We had some discussions about the syntax, but I did think about it a bit
> more and came up with three alternative proposals. Please comment on
> which one seems to be the best in your opinion (or reject all of them
> and propose a fourth one). I tried to be objective and not push for any
> specific one.
>
> Keep in mind that we're working under very tight schedule here and
> client classification is a broad and complex topic. There's a lot we
> could do, but due to the time constraints, we need to be very selective
> for phase 1 (aka Kea 1.0).
>
> Some parts of the design will likely be moved to the requirements page,
> but I want to keep it in the new doc for now, so you could review it
> more easily as one chunk.
>
> It would be great if you could provide your comments by end of this week
> (Oct. 16th), so we could start an implementation the next week.
>
> Thoughts? Comments? Tomatoes?
>
> Tomek
>
> _______________________________________________
> kea-dev mailing list
> [email protected]
> https://lists.isc.org/mailman/listinfo/kea-dev
I echo Thomas?s question about nailing down what the requirements are.
Some general thoughts:
1) Are we going to want to use the expression evaluation code for uses other
than classification?
For example to construct an outgoing option which I don?t believe we allow yet.
This would not
be a feature for the near future but it may suggest if we want the expression
code easily split from
the classification code.
2) Do we have or need a way to specify which relay options to use in the case
that the packet
has traversed multiple relays to get to the server? (I thought I remembered
seeing a discussion
about adding some features in this area some time ago but was unable to find
anything in the
manual.) I think we can probably defer any general work till later but may
need to specify
(in the documentation) what happens in 1.0
3) If I understand it correctly I think G.7 may lead to problems. It sounds
like the intention is to
have multiple classes all named ?FOO? and a class is selected based on which
subnet the client
is in. I think that will end up confusing users and causing configuration
errors.
4) It would be quite useful to have some method to help the admin debug these
things. In ISC DHCP
the standard way is to insert a statement that will log something into the
class definition
or use of class in a subnet. This provides a way for the admin to see if they
wrote the
matching statements correctly for the given clients.
If we go with proposal 1 it would seem simple enough to have the class
definitions be global
while the use of the classes would be only per subnet in phase 1. It would
also seem that we
would then be able to extend the global class definition to add option data in
phase 2.
To me it seems like it will be easier to expand something like proposal 1 into
phase 2 rather
than expanding proposal 2. It also may be a bit easier for people to update
their configuration
files .
While there is a possibility of mis-spelled names in proposal 1 this is similar
to what is done
in ISC DHCP and people don?t seem to have a large problem with it. Overall I
think going
with something where the class definitions are easily split from the options is
a good idea.
I?d also suggest that we be extremely clear in the documentation for whichever
we decide.
In ISC DHCP the classes are global but can be defined within a subnet which
leads to odd
behavior and generally not what the admin expected. This is another reason why
I would
suggest the class definitions be global and only able to be parsed at the
proper level.
3A) Do we have either requirements or goals for the arrangement of classes?
That is
the total number that a user may define? the number per-subnet? Do we expect
that
there may be a large number of classes but only a limited number of them active
for
any subnet? This may affect our decision about defining classes at the subnet
level.
My assumption is that most admins will have a smallish number of classes and
they will
probably be the same classes across most subnets. Though if ISPs use classes to
provide per customer specific information they may end up with a lot of small
classes.
4) I agree with Marcin I think E.6 is probably required. At least I would put
this as the very first
thing on the not required but really want to have list.
5) I also agree with Marcin that F.1 either needs to be broadened or F.3 needs
to be added that
a class can override a subnet. The documentation should be clear on which
option will be used
if a given client could get that option from multiple places. From the current
description
it appears that while a client can be a member of many classes it will only get
options from
one class at a time (I think we can only have one class per subnet currently?).
Eventually
if we allow options at a global level for classes we might want to specify
options are chosen
(or simply state that it is undefined and the admin shouldn?t define an option
in multiple
classes such that a client could get any of them).
6) I?m not sure if the idea is to limit the parsing to a stack of 3 tokens or
that is simply for
example purposes. There are expressions that may take more, though I?m not sure
if we will eventually want them or not. The example I?m thinking of is the
binary-to-ascii
expression. This takes 4 arguments (base, width, separator and data to
format). I don?t think
we will need such a thing in phase 1 but we probably want to write the code to
allow
for expansion in the future and allowing for arbitrary numbers of tokens might
be useful.
------------------------------
_______________________________________________
kea-dev mailing list
[email protected]
https://lists.isc.org/mailman/listinfo/kea-dev
End of kea-dev Digest, Vol 19, Issue 4
**************************************
