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

[Francis Dupont <[e-mail]>]

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]