Subject: [dhcwg] Comments on draft-bhandari-dhc-class-based-prefix

From: "THIEBAUT, LAURENT (LAURENT)" <[email-masked]>
Date: Thu, 5 Apr 2012 14:46:01 +0200

Hello Shwetha, hello all

As a follow up of the discussion we have had in Paris, please a few comments on this very interesting ID
1.      As opposed to the "OPTION_USER_CLASS" whose semantics is undefined and whose impact to the system is loosely defined, the new "PREFIX_CLASS option" allows a well defined structure to ensure inter-operability beyond a corporate proprietary usage, i.e. to make sure that different organisations cannot allocate the same value for the "PREFIX_CLASS option". Indeed the definition and structure and indication of usage of the "User Class Option" is too loose to guarantee inter-operability beyond a corporate deployment

22.15. User Class Option

The User Class option is used by a client to identify the type or category of user or applications it represents.

...

The information contained in the data area of this option is contained in one or more *opaque* fields that represent the user class or classes of which the client is a member.  A server selects configuration information for the client based on the classes identified in this option.  For example, the User Class option can be used to configure all clients of people in the accounting department with a different printer than clients of people in the marketing department.  The user class information carried in this option MUST be configurable on the client.

   ......

(The "User Class Option" can't be used in a non proprietary context as different organisations can by accident allocate the same value to this information)

This comment is an < endorsement" of draft-bhandari-dhc-class-based-prefix

2.      The "PREFIX_CLASS option" should allow to specify

 *   Prefix-classes defined by IETF
 *   Prefix classes defined by other standard fora
 *   (proprietary) Prefix classes defined by a corporate

3.      The proposed structure would be as follows

 *   "Prefix class name space" with 2 values: "IETF" / "other organisation"
 *   "Prefix class owner" (required in case the "Prefix class name space" is "other organisation", not present when "Prefix class name space" is "IETF"). Other organisation may be another standard forum (e.g. BBF) or a corporate.
 *   "Prefix class value" whose structure depends on the "Prefix class name space" and "Prefix class owner"

4.      As the "User Class Option" does not benefit from such structure it cannot be used beyond a corporate proprietary usage. Thus the "User Class Option" cannot provide an interoperable parameter to be used when a DHCP client sends an Information-Request message to obtain (IP) configuration information. Following alternatives may be envisaged:
a)      Either the "PREFIX_CLASS option" is used in Information-Request. It is agreed that the name "PREFIX_CLASS option" would then not be well suited for usage in Information-Request and that thus the name of this option should be changed.
b)      Another possibility is to define a "configuration-information-class option" whose semantics is explicitly made the same as the "PREFIX_CLASS option" and to be used as follows:
o        The DHCP client  puts a "configuration-information-class option"in Information-Request to request that the IP parameters values sent by the DHCP server are determined as the most suitable for the IP service associated with the "configuration-information-class option"
o        when a DHCPv6 client sends a SOLICIT message to request both
*         for IA_NA address allocation from a specific prefix class
*         and to obtain (IP) configuration information using Option Request option (per RFC 3315 section 22.7)
it populates the SOLICIT message as follows:
*         within the IA_NA option, it includes the OPTION_PREFIX_CLASS requesting address to be allocated from a specific prefix class indicated in that option
*         within the Option Request option (per RFC 3315 section 22.7) it includes the "configuration-information-class option" requesting configuration parameters sent by the DHCP server are determined as the most suitable for the IP service associated with the "configuration-information-class option".

If these comments are felt useful, I can provide actual text for the draft.

Best regards

Laurent

---

From: shwethab <[email-masked]>
Date: Wed, 11 Apr 2012 06:39:40 +0530

Hello Laurent,

Thanks for the comments.

I agree that we need structure to Prefix class option  we could have a a
type and value within its content. Type would indicate whether its IETF
defined class or Vendor. Based on the type value can then be interpreted,
may be from a IANA defined name space if it is IETF. I will rework on the
structure of the  option and update the draft.

Regarding including this option in Information request message: if the
semantics and content of configuration-information-class option would be
same as Prefix class, we can rename the Prefix class option suitably or let
the same option be used to request configuration from a specific class in
information request as well.

Thanks,
Shwetha

On 4/5/12 6:16 PM, "THIEBAUT, LAURENT (LAURENT)"
<[email-masked]> wrote:

> 1.     As opposed to the ³OPTION_USER_CLASS² whose semantics is undefined and
> whose impact to the system is loosely defined, the new ³PREFIX_CLASS option²
> allows a well defined structure to ensure inter-operability beyond a corporate
> proprietary usage, i.e. to make sure that different organisations cannot
> allocate the same value for the ³PREFIX_CLASS option². Indeed the definition
> and structure and indication of usage of the ³User Class Option² is too loose
> to guarantee inter-operability beyond a corporate deployment
> 22.15. User Class Option
> Š
> The information contained in the data area of this option is contained in one
> or more *opaque* fields that represent the user class or classes of which the
> client is a member.  A server selects configuration information for the client
> based on the classes identified in this option.  For example, the User Class
> option can be used to configure all clients of people in the accounting
> department with a different printer than clients of people in the marketing
> department. The user class information carried in this option MUST be
> configurable on the client.
>    ŠŠ
> (The ³User Class Option² can¹t be used in a non proprietary context as
> different organisations can by accident allocate the same value to this
> information)
> This comment is an « endorsement² of draft-bhandari-dhc-class-based-prefix
>  
> 2.     The ³PREFIX_CLASS option² should allow to specify
> * ³Prefix class name space² with 2 values: ³IETF² / ³other organisation²
> * ³Prefix class owner² (required in case the ³Prefix class name space² is
> ³other organisation², not present when ³Prefix class name space² is ³IETF²).
> Other organisation may be another standard forum (e.g. BBF) or a corporate.
> * ³Prefix class value² whose structure depends on the ³Prefix class name
> space² and ³Prefix class owner²
>  
>  
> 4.     As the ³User Class Option² does not benefit from such structure it
> cannot be used beyond a corporate proprietary usage. Thus the ³User Class
> Option² cannot provide an interoperable parameter to be used when a DHCP
> client sends an Information-Request message to obtain (IP) configuration
> information. Following alternatives may be envisaged:
> a)     Either the ³PREFIX_CLASS option² is used in Information-Request. It is
> agreed that the name ³PREFIX_CLASS option² would then not be well suited for
> usage in Information-Request and that thus the name of this option should be
> changed. 
> b)     Another possibility is to define a ³configuration-information-class
> option² whose semantics is explicitly made the same as the ³PREFIX_CLASS
> option² and to be used as follows:
> o       The DHCP client  puts a ³configuration-information-class option²in
> Information-Request to request that the IP parameters values sent by the DHCP
> server are determined as the most suitable for the IP service associated with
> the ³configuration-information-class option²
> ·        for IA_NA address allocation from a specific prefix class
> ·        and to obtain (IP) configuration information using Option Request
> option (per RFC 3315 section 22.7)
> ·        within the IA_NA option, it includes the OPTION_PREFIX_CLASS
> requesting address to be allocated from a specific prefix class indicated in
> that option
> ·        within the Option Request option (per RFC 3315 section 22.7) it
> includes the ³configuration-information-class option² requesting configuration
> parameters sent by the DHCP server are determined as the most suitable for the
> IP service associated with the ³configuration-information-class option².
>

---

From: "THIEBAUT, LAURENT (LAURENT)" <[email-masked]>
Date: Fri, 13 Apr 2012 12:04:54 +0200

Hello Shwetha

If you want I can provide you with a written proposal for the modificatio of your draft.

Best regards

Laurent
ALCATEL-LUCENT

________________________________
De : shwethab [mailto:[email-masked]]
Envoyé : mercredi 11 avril 2012 03:10
À : THIEBAUT, LAURENT (LAURENT); [email-masked]
Cc : Sri Gundavelli
Objet : Re: Comments on draft-bhandari-dhc-class-based-prefix

Hello Laurent,

Thanks for the comments.

I agree that we need structure to Prefix class option - we could have a a type and value within its content. Type would indicate whether its IETF defined class or Vendor. Based on the type value can then be interpreted, may be from a IANA defined name space if it is IETF. I will rework on the structure of the  option and update the draft.

Regarding including this option in Information request message: if the semantics and content of configuration-information-class option would be same as Prefix class, we can rename the Prefix class option suitably or let the same option be used to request configuration from a specific class in information request as well.

Thanks,
Shwetha

On 4/5/12 6:16 PM, "THIEBAUT, LAURENT (LAURENT)" <[email-masked]> wrote:

Hello Shwetha, hello all

The information contained in the data area of this option is contained in one or more *opaque* fields that represent the user class or classes of which the client is a member.  A server selects configuration information for the client based on the classes identified in this option.  For example, the User Class option can be used to configure all clients of people in the accounting department with a different printer than clients of people in the marketing department. The user class information carried in this option MUST be configurable on the client.
   ......
(The "User Class Option" can't be used in a non proprietary context as different organisations can by accident allocate the same value to this information)
This comment is an « endorsement" of draft-bhandari-dhc-class-based-prefix

Laurent

---

From: "THIEBAUT, LAURENT (LAURENT)" <[email-masked]>
Date: Wed, 18 Apr 2012 11:32:21 +0200

Hello Shwetha

any answer? are you interested?

Best regards

Laurent
ALCATEL-LUCENT

________________________________
De : THIEBAUT, LAURENT (LAURENT)
Envoyé : vendredi 13 avril 2012 12:05
À : 'shwethab'; [email-masked]
Cc : Sri Gundavelli
Objet : RE: Comments on draft-bhandari-dhc-class-based-prefix

Hello Shwetha

Best regards

Laurent
ALCATEL-LUCENT

Hello Laurent,

Thanks for the comments.

Thanks,
Shwetha

Hello Shwetha, hello all

Laurent

---

From: shwethab <[email-masked]>
Date: Wed, 18 Apr 2012 15:21:58 +0530

Hello Laurent,

Sure, I am working on some of the issues discussed here in the new version.
I will be happy to consider your proposed text in the next revision of the
draft. 

Thanks,
Shwetha

On 4/18/12 3:02 PM, "THIEBAUT, LAURENT (LAURENT)"
<[email-masked]> wrote:

> I agree that we need structure to Prefix class option  we could have a a type
> and value within its content. Type would indicate whether its IETF defined
> class or Vendor. Based on the type value can then be interpreted, may be from
> a IANA defined name space if it is IETF. I will rework on the structure of the
> option and update the draft.
> 
> semantics and content of configuration-information-class option would be same
> as Prefix class, we can rename the Prefix class option suitably or let the
> same option be used to request configuration from a specific class in

---

From: Sri Gundavelli <[email-masked]>
Date: Wed, 18 Apr 2012 07:38:20 -0700

Hi Laurant,

Thanks for your response and also review of the document. We will go over
this comments and update/respond.

Best Regards
Sri