Re: [dhcwg] Gen-ART review of draft-ietf-dhc-container-00

Mike - Can you give a little more detail? I'm not sure I see how theRFC 3046 options - passed between a relay agent and a server - wouldinteract with the container option.

BTW, please feel free to join the conversation at any time. The SFmeeting marked the 20th year anniversary of the first dhc WG meetingat IETF 13 in Cocoa Beach. I was looking at the list of attendees ...and you were at that first meeting, so we welcome your input as acharter member.


Also, from the minutes of that first dhc WG meeting:

  We quickly decided to limit the scope of our discussion to "Internet
  participants" with only a single interface. This decision allowed us
  to avoid the "host versus gateway" and "multi-homed host" religious
  wars...

Guess we won't be able to duck the issue any more.

- Ralph

On Apr 11, 2009, at 4:00 PM 4/11/09, Michael StJohns wrote:

Sorry to stick my oar in, but does this or could this interact withthe options specified in RFC3046 in an unexpected way?


At 01:41 PM 4/11/2009, Ralph Droms wrote:

Scott - even knowing "which interface which DHCP information came
from" may not be enough for a device with multiple interfaces.  Can
policies for merging information be written just based on the
characteristics of the interface - say, 3GPP versus 802.11, or IP
address of the interface - or does the device need to differentiate
between Verizon Wireless and Starbucks if I'm away from home?  Or
differentiate between my AT&T femtocell and my home WiFi network?

- Ralph

On Apr 11, 2009, at 6:00 AM 4/11/09, Scott Brim wrote:

Excerpts from Ralph Droms on Fri, Apr 10, 2009 03:25:49PM -0400:

Scott raises an interesting point about identifying the source of
options when delivered to clients.

BTW, Scott - what is "DHS"?


Sorry, DHCP server

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 evenif

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


Well put.  It all comes down to where information is going to be
merged.  The case where a single RG client connected to multiple SP

servers is essentially already covered by MIF/6man, they just needtodocument it. If the information is merged at the RG server, thenthe

RG server should somehow know which interface which DHCP information
came from.  If all of the information is transparently passed to the
consumer device, then it needs the tags as well.

I don't know how the information could be usefully tagged -- the SP
server's IP address doesn't sound like a good idea.  The WG should

decide if tagging should be included in the container syntax oradded

later (but documented now as needing study).

I'm CCing MIF in case people there aren't on the ietf list.

Thanks ... Scott


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



_______________________________________________
dhcwg mailing list
dhcwg(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/dhcwg


_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf