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

[JORDI PALET MARTINEZ <[e-mail]>]

Hi Rajiv,

I've discussed this with my co-author, and we believe that this document should not define an end-site. This should be (and I guess it is), defined generically for many IETF documents, not just this one.

Similarly, the cellular aspect, it has been already defined in several other documents, even in the latest 3GPP releases. We have some text already about that at the end of section 4, and we have also the case for a cellular device (even a smartphone) acting as a router, which connects an end-site, and in that case, falls also within the scope of this document.

Of course, if the WG believes we should do that, we will do it in a new version.

Regarsd,
Jordi
 
 

-----Mensaje original-----
De: v6ops <[e-mail]> en nombre de "Rajiv Asati (rajiva)" <rajiva=[e-mail]>
Fecha: miércoles, 29 de agosto de 2018, 0:03
Para: Brian E Carpenter <[e-mail]>
CC: "[e-mail]" <[e-mail]>
Asunto: Re: [v6ops] draft-palet-v6ops-rfc6177-bis

    
    This draft should provide a definition for the end-site. Is it a connectivity device such as a home GW/router or consumption device such as a mobile tablet or ...? Answer is all of the above. 
    
    This draft should also explicitly cover cellular/mobile devices that currently get limited to /64, since they could also qualify as end-site. 
    
    Cheers,
    Rajiv Asati
     
    
    
    > On Aug 28, 2018, at 1:11 AM, Brian E Carpenter <[e-mail]> wrote:
    > 
    > 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
    > 
    > _______________________________________________
    > v6ops mailing list
    > [e-mail]
    > https://www.ietf.org/mailman/listinfo/v6ops
    
    _______________________________________________
    v6ops mailing list
    [e-mail]
    https://www.ietf.org/mailman/listinfo/v6ops
    



**********************************************
IPv4 is over
Are you ready for the new Internet ?
http://www.consulintel.es
The IPv6 Company

This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it.