Re: [v6ops] draft-palet-v6ops-rfc6177-bis

[Brian E Carpenter <[e-mail]>]

Hi,

I fully support this draft. Here are a few (minor) wording issues
and some nits.

Issues:
-------
>    [RFC3177] called for a default end-site IPv6 assignment size of /48.
>    Subsequently, the Regional Internet Registries (RIRs) developed and
>    adopted IPv6 address assignment and allocation policies consistent
>    with those recommendations, and it triggered the development of
>    [RFC6177].  However, some of the RIRs, have later on updated those
>    policies, which still allow using /48, but leave the decision in the
>    hands of the ISP, or even, in some cases, encourage the assignment of
>    smaller (e.g., /56) blocks to residential end-sites, while keeping
>    /48 for business.

I don't think that is accurate. Actually there was push-back *from*
the RIRs against the wording of 3177, because some ISPs did not wish
to be consistent with it. Here's another version:

   [RFC3177] called for a default end-site IPv6 assignment size of /48.
   Subsequently, the Regional Internet Registries (RIRs) developed and
   adopted IPv6 address assignment and allocation policies consistent
   with ISP practices, and this triggered the development of [RFC6177].
   Current RIR policies still allow using /48, but leave the decision in the
   hands of the ISP, or even, in some cases, endorse the assignment of
   smaller (e.g., /56) blocks to residential end-sites, while keeping
   /48 for business.

>    This raises the question of a possible misinterpretation of [RFC6177]
>    by at least 1/3rd of the operational community and consequently, the
>    need to revisit it.

No, I don't think there's any misinterpretation. I think it's quite
clear (as in my previous comment) that this is exactly why the ISP
community pushed for RFC6177. I think we should phrase this a bit
differently.

   This raises the question of over-zealous interpretation of [RFC6177]
   by at least one third of the ISP community and consequently, the
   need to revisit it.

>    It might be tempting to give home sites a single /64, since that is
>    already significantly more address space compared with today's IPv4
>    practice.  However, this precludes the certainty that even home sites
>    will grow to support multiple subnets going forward.  Hence, it is
>    strongly intended that even home sites be given a big number of
>    subnets worth of space, by default.  Hence, this document still
>    recommends giving home sites significantly many more than a single
>    /64.

I think a reference to RFC7368 and RFC7788 would be useful here, to make
it clear that this is not guesswork. (Note that HNCP is mentioned later,
so there is a little repetition in the argument.)

Nits:
-----

> Abstract
>
>   The Regional Internet Registries (RIRs) policies, have different
Delete the comma

>   requires an ever-increasing availability of subnets at the end-site
>   and so, policy should reflect that assignment of a single subnet is

NEW
   requires an ever-increasing availability of subnets at the end-site,
   so policy should reflect that the assignment of a single subnet is

I see a number of other minor syntax and punctuation nits in the
text, but I'm afraid I'm going to leave those for the copy-editor.

Regards,
     Brian