RE: draft-ietf-v6ops-ipv6-cpe-router-03.txt WGLC

["Dan Wing" <dwing@cisco.com>]

> -----Original Message-----
> From: Ole Troan [mailto:ot@cisco.com] 
> Sent: Thursday, January 07, 2010 2:54 AM
> To: Dan Wing
> Cc: 'Fred Baker'; v6ops@ops.ietf.org; kurtis@kurtis.pp.se; 
> rbonica@juniper.net; draft-ietf-v6ops-ipv6-cpe-router@tools.ietf.org
> Subject: Re: draft-ietf-v6ops-ipv6-cpe-router-03.txt WGLC
> 
> Dan,
> 
> thanks for extensive comments!
> 
> [removed DNS comment. as I have nothing to add. I'd really 
> like a consensus coming out of v6ops/behave for any new or 
> different CPE requirements]
> 
> > Section 3.1 should additionally mention that an end-network
> > IPv4 CPE that incorporates a NAT also incorporates a DHCPv4 
> > server.  The inclusion of a DHCP server in the CPE is implied, 
> > but should be explicitly stated.  The DHCP server in the CPE 
> > allows the in-home network to be self-sufficient (for IP 
> > addressing, if not naming).
> > 
> > This is relevant to IPv6 because, I have been told, ULAs
> > provide a similar "LAN only" address.  This should be
> > mentioned or a pointer to how hosts inside the home should
> > use ULAs mentioned.  We do not want streaming between an
> > in-home NAS and an in-home television to rely on the
> > WAN link's availability.  This is mentioned (insufficiently)
> > in Section 4.2 and some of the L-* requirements.
> 
> agree. added your proposed text in section 3.1
> 
> > The definition of Service Provider is "a company that ...",
> > which precludes non-companies such as, for example, a University 
> > offering service to students in University housing.  Is 
> that intentional?
> 
> <t hangText="Service Provider">an entity that provides
>           access to the Internet. In this document, a Service Provider
>           specifically offers Internet access using IPv6, and may also
>           offer IPv4 Internet access. The Service Provider can provide
>           such access over a variety of different transport methods
>           such as DSL, cable, wireless, and others.</t>
> 
> is the above text any better? "entity" is quite fluffy, but 
> what can you do...

Works for me.  Thanks.

> > Many of the enumerated requirements contain multiple 
> "MUSTs" or "SHOULDs".
> > This makes things complicated, because a vendor (or a 
> customer) cannot say,
> > for example, "we comply with all of RFCxyz, except L-5" 
> because L-5 contains
> > three MUSTs and one SHOULD.  Taking L-5 as an example, I 
> suggest changing
> > from:
> > 
> > OLD:
> >   L-5:   The IPv6 CE router MUST assign a separate /64 from its
> >          delegated prefix (and ULA prefix if configured to 
> provide ULA
> >          addressing) for each of its LAN interfaces.  The IPV6 CE
> >          router MUST make the interface an advertising interface
> >          according to [RFC4861].  In router advertisements messages,
> >          the Prefix Information Option's A/L-bits MUST be 
> set to 1 by
> >          default; the A/L bits setting SHOULD be user configurable.
> > NEW:
> >   L-5:   a. The IPv6 CE router MUST assign a separate /64 from its 
> >             delegated prefix (and ULA prefix if configured to 
> >             provide ULA addressing) for each of its LAN interfaces.
> >          b. The IPV6 CE router MUST make the interface an 
> advertising 
> >             interface according to [RFC4861].  
> >          c. In router advertisements messages, the Prefix 
> Information 
> >             Option's A/L-bits MUST be set to 1 by default; 
> >          d. the A/L bits setting SHOULD be user configurable.
> > 
> > 
> > This would allow a vendor (or a customer) to say "we comply 
> with all of
> > RFCxyz, except L-5c and L5-d".
> 
> 
> I agree with this suggestion.

-d