Re: [dhcwg] WGLC for draft-ietf-dhc-sedhcpv6-04 - Respond by Nov 3, 2014

[Sheng Jiang <[e-mail]>]

Hi, Francis,

Thanks for your careful review and support. We will address your comments with other comments during the WGLC and produce an updated version before submission for publication.

Best regards,

Sheng

>-----Original Message-----
>From: dhcwg [mailto:[e-mail]] On Behalf Of Francis Dupont
>Sent: Tuesday, November 04, 2014 7:05 AM
>To: Bernie Volz (volz)
>Cc: [e-mail]
>Subject: Re: [dhcwg] WGLC for draft-ietf-dhc-sedhcpv6-04 - Respond by Nov
>3, 2014
>
>draft-ietf-dhc-sedhcpv6-04.txt review:
> - 4 page 5: there is no server authorization. This could be an issue
>  but in fact it is something which can't be supported by a booting
>  client (i.e., its requires an access to the Internet which is not
>  yet available).  So I agree we can give up or postpone it.
>
> - 4.2 page 6: the algo agility can be inter or intra message. The
> wording "various algorithms simultaneously" is ambiguous when
> it is clearly between messages (i.e., there is one algo used in a
> particular message so the agility applied to two or more different
> messages).
>
> - 5.2 page 8: add "public key" before certificate (because X.509
>  defines attribute certificates too).
>
> - 5.4 page 10: "fixed-point number" and "in seconds" is not the
>  best wording: the second unit applies to the integral part.
>  I don't know if we should fix this before the IETF LC.
>
> - 6.1 page 11: the client must have a certificate ->
>  a public key certificate and its corresponding private key.
>
> - 6.1 page 12: the mandatory algorithms -> one of the mandatory
>  algorithms (BTW as there is only one mandatory algo this is not
>  a visible change).
>
> - 6.1 page 12: the behavior on TimestampFail error could be better
>  than to go to unsecured mode: the client can use timestamp options
>  in messages received from the server to synchronize with it before
>  retrying. Of course this requires these messages are validated so
>  it can't be specified in a few word... BTW the MAY is still valid,
>  it is just not the only option.
>
> - 6.2 page 13: IMHO the paragraph must be break just before
>  "The message that fails authentication check MUST be"
>
> - 6.2 page 14: I have a question about to add a SHOULD for adding
>  a timestamp option in TimestampFail error messages. IHMO there is
>  an implicit recommendation to use TS option in responses to queries
>  carrying a TS, even there is no TS requested in the ORO...
>
> - 7.1 page 16: i.e. -> i.e.,
>
> - 9 page 19: I believe we should remove the SHA-1 from the beginning
>  i.e., now. And we have the opportunity to use more state of crypto,
>  for instance better RSA signing than RSASSA-PKCS1-v1_5 or to jump
>  to ECDSA. Note I propose to keep the current mandatory choice for
>  legacy: we should get some advice from a cryptographer...
>
> - Authors' Addresses pages 22 and 23: RFC 7322 asks the country
>  in postal addresses is the ISO IS 3166 two letter code (I believe
>  it is an error as this is not what to use in a postal address but
>  it seems RFC 7322 (the new RFC style guide) will be enforced before
>  it will be fixed...).
>
>Thanks
>
>[e-mail]
>
>_______________________________________________
>dhcwg mailing list
>[e-mail]
>https://www.ietf.org/mailman/listinfo/dhcwg