Scott raises an interesting point about identifying the source of
options when delivered to clients.
BTW, Scott - what is "DHS"?
The usual case - almost the only case today - is that there is a
single upstream service provider and a single source of DHCP options
to be passed along to the client. In this scenario, there's no need
to pass along any information identifying the source of the options.
To allow for a multihomed subscriber network, I can imagine adding a
tag that would be passed along with the options so the subscriber
client can identify the source of each option. But, what would the
client do with that information? How would the client interpret it?
What is the syntax and semantics of the tagging?
Taken a step farther, sourcing information might be required even if
there is no intermediate RG and the contained option is not in use.
How does a device with multiple interfaces make policy decisions about
information received on those multiple interfaces (which is pretty
much the question Scott asks about the container option)?
- Ralph
On Apr 7, 2009, at 2:25 PM 4/7/09, Scott Brim wrote:
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 wait for direction from your document shepherd
or AD before posting a new version of the draft.
Document: draft-ietf-dhc-container-00
Reviewer: Scott Brim
Review Date: 7 April 2009
IESG Telechat date: 14 April 2009
Summary:
This draft is on the right track but has open issues.
Comments:
More significant:
I am concerned about multiple interface scenarios as are being
discussed in MIF and 6MAN, where either the RG is multiply connected
or the end device is. For a discussion of the sort of problems that
lead to this concern, see (for example) notes from the MIF BOF at
IETF74.
- There must be a way to associate options with a particular
upstream DHS they were obtained from, when the container is passed
to the RG server and perhaps to the end device. This source
information may or may not be in the container itself -- that's up
to the WG to decide. If it is decided that the source information
will not be part of the container syntax, at least the fact that
it is necessary should be documented for people who ultimately do
specify how container options are passed.
- The SP server may have its ideas of how a consumer device should
be configured, but it is not appropriate to say that the "SP
server MUST be able to control which DHCP options are transmitted
to the consumer device". The RG server may need to make decisions
about information from multiple DHCP servers. Perhaps you could
say that the SP server MUST be able to "provide information" to
the RG server.
Less significant:
5.1 and 5.2
Alignment between the v4 and v6 descriptions would be better. The
v4 description has "code" in the diagram and says that "code" is
OPTION_CONTAINER_V4. The v6 description has "OPTION_CONTAINER_V6"
in the diagram and says that "option-code" is OPTION_CONTAINER_V6.
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf