Re: [dhcwg] FW: dhcwg Digest, Vol 159, Issue 22

Francis Dupont <> Thu, 27 July 2017 19:54 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 15A0C12EC1D for <>; Thu, 27 Jul 2017 12:54:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.902
X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id nwZ9XUE4huoW for <>; Thu, 27 Jul 2017 12:54:28 -0700 (PDT)
Received: from ( [IPv6:2001:41d0:1:6d55:211:5bff:fe98:d51e]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 135981287A5 for <>; Thu, 27 Jul 2017 12:54:27 -0700 (PDT)
Received: from (localhost [IPv6:::1]) by (8.14.7/8.14.7) with ESMTP id v6RJbVE4096463; Thu, 27 Jul 2017 21:37:31 +0200 (CEST) (envelope-from
Message-Id: <>
From: Francis Dupont <>
To: Srinivasa Rao Nalluri <>
cc: "" <>
In-reply-to: Your message of Wed, 26 Jul 2017 06:42:26 -0000. <>
Date: Thu, 27 Jul 2017 21:37:31 +0200
Archived-At: <>
Subject: Re: [dhcwg] FW: dhcwg Digest, Vol 159, Issue 22
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 27 Jul 2017 19:54:30 -0000

 In your previous mail you wrote:

>  Thank you for review and comments. Please see my response inline prefixed
>  with [Srinivas]
>  [Srinivas] We already have an RFC that talks about encoding larger content
>  in DHCPv4 option. So, I mentioned following in section 4.
>     "Maximum possible value of DHCPv4 "option-len" is 255.
>  LWM2M-server-certificate MAY be of length more than 255.  To accommodate
>  larger
>     certificate, DHCP server SHOULD follow encoding as mentioned in
>  [RFC3396]."

=> IMHO it is not the best idea, i.e., in place of relying on a
complex (and not very deployed) extension it is better to just
encourage encodings which don't lead to large options.

>   - as IKEv2 is over UDP too this problem is addressed in RFC 7296 by
>    allowing many different "encodings" (currently 15 in the IANA
>    registry).
>  So I am afraid authors just took a good text about certificate transport
>  (BTW I'd pick the same one so my concern is not about the choice) but missed
>  to add an additional statement about application.
>  I propose:
>   - add something about the encoding byte so nobody will forget to read
>    RFC 7296 and for instance put a X.509 certificate as the whole content
>  [Srinivas] I need a bit more clarity on this comment. Encoding byte is
>  explained in RFC 7296. It will be same even if we explain in our draft. Is
>  that ok to repeat details of "cert encoding" byte of section 3.6, RFC7296? 
>  Or 
>  Do you say that option format defined in section 3.2 "DHCPv6 option for
>  LWM2M server certificate" should include "cert encoding" byte and same
>  should be explicitly explained in our draft?
>  I see later makes more sense.

=> IMHO it is enough to mention the encoding byte but of course the
second solution (add the byte in the figure) is both simple and
efficient so obviously the best.

>   - make a few encodings mandatory to support (*)
>  [Srinivas] I will check what formats/encodings make more sense in LWM2M
>  deployments and I will add them as mandatory list in next version of draft.

=> thanks