Subject: [Gen-art] review of draft-ietf-mip6-hiopt-10.txt

From: Francis Dupont <[email-masked]>
Date: Wed, 30 Jan 2008 17:14:21 +0100

I have been selected as the General Area Review Team (Gen-ART)
reviewer for this draft (for background on Gen-ART, please see
http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html).

Please resolve these comments along with any other Last Call comments
you may receive.

Document: draft-ietf-mip6-hiopt-10.txt
Reviewer: Francis Dupont
Review Date: 2008-01-30
IETF LC End Date: 2008-02-04
IESG Telechat date: unknown

Summary: Not ready

Comments: I have three series of comments: editorial (which should be
handled by the RFC editor but you may fix them if (and only if) you
publish a new version for a different reason), formal and not-formal.

Editorial comments:
 - ToC page 2 and 7 page 18: s/Acknowledgements/Acknowledgments/
 - 4.2 page 13: the [Editor's note] is a sure source of editorial issues
  (for instance the abbrev AVP)
 - 4.2 page 13: s/OPTION_CLIENTID/Client-id option/
 - 4.[23] page 14: s/Relay Message/Relay-message/
 - 4.2 page 14: s/Information Request/Information-request/
 - please use the same spelling for pre(-)configured along.

Formal comments:
 - you should explain in 1 (introduction) or 3 (options) that DHCP
  is used to get informations, not resources (so the client uses
  an Information-request message in the framework described by
  the RFC 3736 ("Stateless DHCPv6")) with a HN Identifier/Information
  option exchange. (I'll come back to this in not-formal comments).
 - 3.1 page 6: the HN Identifier field must be marked as optional.
 - 3.2.1 page 8: the HN Information is not to be provided to a
  mobile node because the MIP6 relay agent option is sent to a server.
 - 4.1 page 12: why the "should" for the two not more than one is not
  a SHOULD?
 - 4.2 page 13: RFC 3315 allows a chain of relays so the SHALL to the
  DHCP server should be relaxed.
 - 4.2 page 14: a second "to the DHCP server"
 - 4.2 page 14: the Relay-message (- and lower case m) option of the
  Relay-reply message carries a Reply, not an Information-request.
 - 4.3 page 14: the MIP6 Relay Agent option is not in the Information-
  request message.

Not-formal comments:
 - I don't like to use DHCPv6 as a service discovery protocol as it was
  designed to assign resources. But as the RFC 3736 narrowed the protocol
  to this kind of things it is a matter of taste (but please explain
  this point and cite the RFC).
 - the HN Identifier/Information is not at all in the style of DHCPv6
  which uses two (other) ways:
   * ORO when the client just says it'd like to get it
   * options, including skeleton options when the client has to say more,
    even it is just the number of options in the answer
  Applied to the Home Network options, they should be merged and the
  Identifier become a sub-option.
 - ORO doesn't make sense for HN Information (nor more it makes sense
  for IAs). ORO could be used to replace the id-type 2 but IMHO it
  is not a good idea.
 - as a DHCPv6 implementor, I don't like at all optional fields (and
  the HN Indentifier is an optional field
 - IMHO the V flag should be in the option itself, not in sub-options
 - the architecture enforces the NAS to be the first (and even the only)
  DHCP Relay. There is no good reason for this constraint and a better
  wording can remove it, i.e., the only point to keep is the excellent
  idea to collocate the NAS and the DHCP agent
 - Quoting RFC 4580/4649 this statement should be added about server
  behavior with MIP6 Relay Agent option:
  "There is no requirement that a server return this option and its data
   in a Relay-reply message."
 - the MIP6 Relay Agent option is brain damaged: either the relay doesn't
  know the infos to answer and it forwards the request to the next agent,
  or it knows and it is silly to insert the answer in an agent option when
  it is so simple to just answer. So in place of to get an active relay
  with a passive server I propose to follow the architecture of DHCPv6
  as it was designed and to use an agent which is a relay or a server
  according it can answer or not (note as a relay may forward a request
  to multiple servers the "or" is not exclusive and an ORO for a very
  not-MIP6 option is not an issue).
 - the SHALL for the exclusive use of the Client-id for the MN
  identification should be removed as it is very unlikely the NAS knows
  the MN's DUID. BTW the Client-id option is not mandatory in
  Information-requests...
 - finally, prefixes have lifetimes when informative options have none
  (and RFC 4242 is Information-request wide) so I propose to reuse
  the ia-prefix option layout in HN prefix sub-option

Thanks

[email-masked]

PS: as the last call is still open you can consider my not-editorial
comments as last call comments, i.e., if you ask I can cut & past them
to the MEXT and/or DHC list.

_______________________________________________
Gen-art mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/gen-art