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 PROTECTED]
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
Gen-art@ietf.org
https://www1.ietf.org/mailman/listinfo/gen-art
