Hi Bernie, Thanks for your feed back. See my comments in the text.
On Mon, Oct 21, 2013 at 3:09 AM, Bernie Volz (volz) <[email protected]> wrote: > These are comments with WG co-chair hat off. > > I don't recall providing input to this document: > > 11 > <http://tools.ietf.org/html/draft-mglt-homenet-naming-architecture-dhc-options-00#section-11>. > Acknowledgment > > We would like to thank Tomasz Mrugalski and Bernie Volz for their > comments on the design of the DHCP Options. > > > We received comments and recommendations from the previous version on Jul 05 -- Basically splitting the complex option we proposed, and following (and reading) the guide lines. We expected to present our new design at IETF87, but ran out schedule. And at first glance this looks like encapsulation gone crazy!! > This is also my opinion. My understanding of the option guidelines was to use encapsulation of options instead of specific format. We might have mis-understood something or gone too far. Either ways I am very glad to have your feed backs. We can easily remove some encapsulations. > I haven't yet read it carefully enough to determine whether this makes > sense to do. > > There is no complex or hidden reasons for encapsulation. We might have done it the wrong way. This version is expected to be a document for discussion. We hope next versions converge quickly. > I don't like things like requiring a server to return "empty" options if > it "understands" them but they were not configured (or "badly" configured). > And I can't see any benefit to the client for doing this documented > (there's no special action the client is specified to take) -- so why do it? > > The only benefit for the client is that it can decide between sending a message with "Options not supported" or "Badly configured Homenet Naming Architectures". We can remove this requirement. > - Bernie (from iPad) > > On Oct 20, 2013, at 3:52 PM, "Daniel Migault" <[email protected]> wrote: > > Hi, > > Please find a description of DHCP options intended to configure the "IPv6 > Home Network Naming Delegation". [1] > > Feel free to make comments! > > Best Regards, > Daniel > > URL: > http://www.ietf.org/internet-drafts/draft-mglt-homenet-naming-architecture-dhc-options-00.txt > Htmlized: > http://tools.ietf.org/html/draft-mglt-homenet-naming-architecture-dhc-options-00 > > [1] > http://www.ietf.org/internet-drafts/draft-mglt-homenet-front-end-naming-delegation-03.txt > > > > ---------- Forwarded message ---------- > From: <[email protected]> > Date: Sun, Oct 20, 2013 at 9:41 PM > Subject: New Version Notification for > draft-mglt-homenet-naming-architecture-dhc-options-00.txt > To: Wouter Cloetens <[email protected]>, Chris Griffiths < > [email protected]>, Daniel Migault <[email protected]>, Ralf Weber < > [email protected]> > > > > A new version of I-D, > draft-mglt-homenet-naming-architecture-dhc-options-00.txt > has been successfully submitted by Daniel Migault and posted to the > IETF repository. > > Filename: draft-mglt-homenet-naming-architecture-dhc-options > Revision: 00 > Title: DHCP DNS Public Authoritative Server Options > Creation date: 2013-10-20 > Group: Individual Submission > Number of pages: 35 > URL: > http://www.ietf.org/internet-drafts/draft-mglt-homenet-naming-architecture-dhc-options-00.txt > Status: > http://datatracker.ietf.org/doc/draft-mglt-homenet-naming-architecture-dhc-options > Htmlized: > http://tools.ietf.org/html/draft-mglt-homenet-naming-architecture-dhc-options-00 > > > Abstract: > The home network naming architecture as described in [I-D.mglt- > homenet-front-end-naming-delegation] requires a complex naming > configuration on the CPE. This configuration MAY not be handled > easily by the average end user. Furthermore, such misconfiguration > MAY result in making home network unreachable. > > This document proposes a DHCP options that provide the CPE all > necessary parameters to set up the home network naming architecture. > > First, this DHCP options provide automatic configuration and avoid > most end users' misconfiguration. Most average end users may not > require specific configuration, and their ISP default configuration > MAY fully address their needs. In that case, the naming homenet > architecture configuration will be completely transparent to the end > users. Then, saving naming configuration outside the CPE, makes it > resilient to change of CPE or CPE upgrades. Such configuration may > also be configured by the end user, via the customer area of their > ISP. > > > > > Please note that it may take a couple of minutes from the time of > submission > until the htmlized version and diff are available at tools.ietf.org. > > The IETF Secretariat > > > > > -- > Daniel Migault > Orange Labs -- Security > +33 6 70 72 69 58 > > _______________________________________________ > > dhcwg mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/dhcwg > > -- Daniel Migault Orange Labs -- Security +33 6 70 72 69 58
_______________________________________________ homenet mailing list [email protected] https://www.ietf.org/mailman/listinfo/homenet
