Curtis,
I agree with your addition of that paragraph with the one exception of
removing the "at no additional cost" phrase. I agree it should be that
way but it is up to the individual ISP and not the IETF as to what
should and should not be charged for.
Yes, lets move on.
Best regards,
Jeff Bowden
On 10/3/2012 12:36 PM, Curtis Villamizar wrote:
In message <506be6ae.5070...@globis.net>
Ray Hunter writes:
Why not just add RFC 6177 BCP 157
http://www.rfc-editor.org/bcp/bcp157.txt as a normative reference in
draft-ietf-homenet-arch?
That's a lot shorter than re-hashing the whole discussion within Homenet.
Clearly some providers aren't getting it so repitition may help, but
not repitition of the entire argument made in RFC6177.
For example:
This document obsoletes RFC 3177, updating its recommendations in the
following ways:
1) It is no longer recommended that /128s be given out. While
there may be some cases where assigning only a single address
may be justified, a site, by definition, implies multiple
subnets and multiple devices.
One provider is doing a trial allocating /128 addresses and alegedly
targeting this at *business service*. /64 later (no date). shorter
prefixes still later (also no date). So either they are not reading
RFC6177 or they are not getting it.
Wording which refers to RFC6177 would help. Adding the one sentence
below to that would also help. How about:
If home networks are to avoid having to subdivide /64s, then
consumer oriented service providers MUST allow customers to easily
request and get prefixes shorter than /64 and SHOULD provide these
shorter prefixes at no additional cost. Allocation of shorter
prefixes than /64 is recommended in RFC 6177 BCP 157 [RFC6177].
If there is no objections we can end this part of the thread and move
on to the rest of the suggested changes to the draft.
Curtis Villamizar wrote:
Now that we beat summary item #12 to death, can we please turn our
attention to the remaining 18 summary items listed below and the diffs
to the draft?
btw- I think the concensus on summary item #12 is that maybe we can
add the following points to the framework. Subnets longer than /64
are bad. Some devices don't support DHCPv6, therefore SLAAC is
essential. Consumer oriented service providers of must allow
customers to easily request and get prefixes shorter than /64 and
preferably at no additional cost if we are to avoid having to
subdivide /64s.
Curtis
[ ... trim ... ]
I think your reply was just concerning the above paragraph so I
trimmed the rest.
Curtis
_______________________________________________
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet
_______________________________________________
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet
