Re: [homenet] Fwd: New Version Notification for draft-mglt-homenet-front-end-naming-delegation-03.txt

[Daniel Migault <[e-mail]>]

Hi Dominique,

Thank you for the comment. I am fine with having a 1 or 7 days value for
expire. I do not thing it increases to much load.

Any opinion on that?

Daniel


On Tue, Oct 22, 2013 at 5:04 PM, <[e-mail]> wrote:

>  Hi Daniel, ****
>
> I have one remark regarding 5.2 paragraph and EXPIRE parameter.****
>
> It seems to me that the value by default (i.e.: 42 days) is too large.
> Actually, if we take the case where the CPE is unavailable for a long time
> (e.g.: CPE switched-off), the association fqdn1/IP1 will stay valid in the
> Public authoritative masters. The IP Prefix Allocation module (e.g.: DHCP
> Server) could re-allocate the prefix to another CPE. Therefore host behind
> this CPE could be assigned with same IP Address (i.e.:IP1). In the Public
> authoritative masters, we could then have associations for fqdn1/IP1 and
> fqdn2/IP1. As a consequence, the resolution of fqdn1 will point to the
> wrong CPE.****
>
> I would prefer to decrease the value of EXPIRE (e.g.: 1 or 7 days maximum)
> depending of operator’s policies for re-attribution of IP Prefix.****
>
> ** **
>
> *Dominique *****
>
> ** **
>
> *De :* [e-mail] [mailto:[e-mail]] *De la
> part de* Daniel Migault
> *Envoyé :* dimanche 20 octobre 2013 21:48
> *À :* [e-mail]
> *Objet :* [homenet] Fwd: New Version Notification for
> draft-mglt-homenet-front-end-naming-delegation-03.txt****
>
> ** **
>
> Hi, ****
>
> ** **
>
> Please find our draft presenting the "IPv6 Home Network Naming
> Delegation". ****
>
> ** **
>
> URL:
> http://www.ietf.org/internet-drafts/draft-mglt-homenet-front-end-naming-delegation-03.txt
> Htmlized:
> http://tools.ietf.org/html/draft-mglt-homenet-front-end-naming-delegation-03
> ****
>
> ** **
>
> Feel free to make comments!****
>
> ** **
>
> Best Regards, ****
>
> ** **
>
> Daniel****
>
> ---------- Forwarded message ----------
> From: <[e-mail]>
> Date: Sun, Oct 20, 2013 at 9:41 PM
> Subject: New Version Notification for
> draft-mglt-homenet-front-end-naming-delegation-03.txt
> To: Wouter Cloetens <[e-mail]>, Chris Griffiths <
> [e-mail]>, Daniel Migault <[e-mail]>, Ralf Weber <
> [e-mail]>
>
>
>
> A new version of I-D, draft-mglt-homenet-front-end-naming-delegation-03.txt
> has been successfully submitted by Daniel Migault and posted to the
> IETF repository.
>
> Filename:        draft-mglt-homenet-front-end-naming-delegation
> Revision:        03
> Title:           IPv6 Home Network Naming Delegation
> Creation date:   2013-10-20
> Group:           Individual Submission
> Number of pages: 19
> URL:
> http://www.ietf.org/internet-drafts/draft-mglt-homenet-front-end-naming-delegation-03.txt
> Status:
> http://datatracker.ietf.org/doc/draft-mglt-homenet-front-end-naming-delegation
> Htmlized:
> http://tools.ietf.org/html/draft-mglt-homenet-front-end-naming-delegation-03
> Diff:
> http://www.ietf.org/rfcdiff?url2=draft-mglt-homenet-front-end-naming-delegation-03
>
> Abstract:
>    CPEs are designed to provide IP connectivity to home networks.  Most
>    CPEs assigns IP addresses to the nodes of the home network which
>    makes it a good candidate for hosting the naming service.  With IPv6,
>    the naming service makes nodes reachable from the home network as
>    well as from the Internet.
>
>    However, CPEs have not been designed to host such a naming service
>    exposed on the Internet.  This MAY expose the CPEs to resource
>    exhaustion which would make the home network unreachable, and most
>    probably would also affect the home network inner communications.
>
>    In addition, DNSSEC management and configuration may not be well
>    understood or mastered by regular end users.  Misconfiguration MAY
>    also results in naming service disruption, thus these end users MAY
>    prefer to rely on third party naming providers.
>
>    This document describes a homenet naming architecture where the CPEs
>    manage the DNS zone associates to its home network, and outsource
>    both DNSSEC management and naming service on the Internet to a third
>    party designated as the Public Authoritative Servers.
>
>
>
>
> 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
> [phone] ****
>
> _________________________________________________________________________________________________________________________
>
> Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
> pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
> a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
> Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.
>
> This message and its attachments may contain confidential or privileged information that may be protected by law;
> they should not be distributed, used or copied without authorisation.
> If you have received this email in error, please notify the sender and delete this message and its attachments.
> As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
> Thank you.
>
>


-- 
Daniel Migault
Orange Labs -- Security
[phone]