Re: [v6ops] Benjamin Kaduk's Discuss on draft-ietf-v6ops-transition-ipv4aas-13: (with DISCUSS and COMMENT)

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

Hi Benjamin,

Thanks for your review. I saw your earlier comments earlier this morning, but only got this email right now.

I will check all the detailed suggestions, but I'm sure some of them have already been resolved in -13 (submitted earlier today), such as breaking long sentences and a few others.

Even if the subject of the emails says -13, I think you've been reviewing -12, but I will make sure to follow all them anyway, I guess is some kind of failure with the tools.

Regards,
Jordi
 
 

-----Mensaje original-----
De: v6ops <[e-mail]> en nombre de Benjamin Kaduk <[e-mail]>
Fecha: jueves, 10 de enero de 2019, 15:50
Para: The IESG <[e-mail]>
CC: <[e-mail]>, <[e-mail]>, <[e-mail]>
Asunto: [v6ops] Benjamin Kaduk's Discuss on draft-ietf-v6ops-transition-ipv4aas-13: (with DISCUSS and COMMENT)

    Benjamin Kaduk has entered the following ballot position for
    draft-ietf-v6ops-transition-ipv4aas-13: Discuss
    
    When responding, please keep the subject line intact and reply to all
    email addresses included in the To and CC lines. (Feel free to cut this
    introductory paragraph, however.)
    
    
    Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
    for more information about IESG DISCUSS and COMMENT positions.
    
    
    The document, along with other ballot positions, can be found here:
    https://datatracker.ietf.org/doc/draft-ietf-v6ops-transition-ipv4aas/
    
    
    
    ----------------------------------------------------------------------
    DISCUSS:
    ----------------------------------------------------------------------
    
    I guess this is related to Suresh's Discuss as well.
    
    It's late in the day and I'm reading quickly, so my apologies if I've
    missed something obvious and this is in fact a non-issue.  That said,
    process-wise, it seems that 464XLAT-6 in Section 3.2.1 is attempting to
    direct an implementation of RFC 8115 to violate a MUST-level requirement
    from that document ("the conveyed multicast IPv6 prefix MUST belong to the
    [ASM|SSM] range") by allowing for all-zero ASM_mPrefix64 and SSM_mPrefix64
    fields.  (Furthermore, the end of Section 3 of RFC 8115 appears to suggest
    that the Well-Known DNS Name heuristic discovery-based method should be
    used instead, when only unicast services are needed.)
    
    
    ----------------------------------------------------------------------
    COMMENT:
    ----------------------------------------------------------------------
    
    [note: I reviewed the -12 version, as the -13 arrived during the middle of
    my review and I wanted to remain internally consistent]
    
    I don't think that making "DEFAULT" a capitalized keyword adds any value;
    the one usage reads fine with "default" in lowercase.
    
    Section 1
    
       These routers rely upon "Basic Requirements for IPv6 Customer Edge
       Routers" [RFC7084], so the scope of this document is to ensure the
       IPv4 "service continuity" support, in the LAN side, ensuring that
       remote IPv4-only services are accessible, from an IPv6-only Internet
       Service Provider access network (typically referred as WAN - Wide
       Area Network, even in some cases it may be metropolitan, regional,
       etc.) even from IPv6-only applications or devices in the LAN side.
    
    nit: this is a single very-long sentence.  I suggest breaking it into two
    or three smaller ones (e.g., break after "in the LAN side".
    
       device, causing IPv4 addresses to become prohibitive expense.  This,
    
    nit: "a prohibitive expense" or "prohibitively expensive"
    
       Since it is impossible to know prior to sale which transition
       mechanism a device will need over its lifetime, IPv6 Transition CE
       Router intended for the retail market MUST support all the IPv4aaS
       transition mechanisms supported by this document.  Service providers
    
    nit: it's probably more "listed in" this document than "supported by".
    
    Section 1.1
    
    I think it would be okay to just use the normal BCP 14 boilerplate, even
    though this is an information document placing (opt-in) requirements on
    devices to be used in a certain use case.
    
    Section 3.2
    
       TRANS-2:  The IPv6 Transition CE Router MUST have a GUI, CLI and/or
                 API option to manually enable/disable each of the supported
                 transition mechanisms.
    
    Do we really need to pick and name interfaces, or can we just say "MUST
    have a configuration interface"?
    
       TRANS-3:  If an IPv6 Transition CE Router supports more than one LAN
                 subnet, the IPv6 Transition CE Router MUST allow
                 appropriate subnetting and configuring the address space
    
    nit: perhaps "configuration of"?
    
                 (which may depend on each transition mechanism) among the
                 several interfaces.  In some transition mechanisms, this
                 may require differentiating mappings/translations per
                 interfaces.
    
    nit: perhaps "different mappings/translations" or "differentiating
    mappings/translations on a per-interface basis"
    
       CONFIG-1:  Request the relevant configuration options for each
                  supported transition mechanisms, which MUST remain
                  disabled at this step.
    
    This seems like it could make for really bad UX in some cases, such as when
    a user is only given one class of configuration information from their ISP
    and is hopelessly confused by questions (about other mechanisms) that they
    don't have answers for.  Is the MUST requirement (not quoted) to follow
    this step really justified?
    
    Section 3.2.1
    
                                                     If 464XLAT is
       supported, it MUST be implemented according to [RFC6877].  [...]
    
    Do we want to consider adding "or a successor document"?
    
       464XLAT-1:  The IPv6 Transition CE Router MUST perform IPv4 Network
                   Address Translation (NAT) on IPv4 traffic translated
                   using the CLAT, unless a dedicated /64 prefix has been
    
    "MUST, unless" is sometimes an awkward formulation.  In general, even
    reordering to "Unless X, Y MUST ..." is frequently an improvement.
    
                   Plain IPv6 mode (i.e., no IPv4-in-IPv6 encapsulation is
                   used) MUST be used to send PCP requests to the server.
    
    What entity does this requirement apply to (and under what conditions, if
    any)?
    
       464XLAT-7:  The priority for the NAT64 prefix, in case the network
                   provides several choices, MUST be: 1) [RFC7225], 2)
                   [RFC8115], and 3) [RFC7050].
    
    I'm not entirely sure why this has to be a MUST -- a SHOULD would leave
    room for implementations to have different preferences, say, if they like
    DHCP discovery more than PCP.
    
                                                            If DNS64
       [RFC6147] is not used, or not trusted, as the DNS configuration at
       the CE (or hosts behind the CE) may be modified by the customer, then
       the service provider may opt to configure the NAT64 prefix either by
       means of [RFC7225] or [RFC8115], which also can be used if the
       service provider uses DNS64 [RFC6147].
    
    This is another long and convoluted sentence.  If I am correct in inferring
    that "as the DNS configuration at the CE (or hosts behind the CE) may be
    modified by the customer" is intended to justify not trusting DNS64, then I
    suggest putting it in parentheses (in which case the now-internal
    parenthetical could be changed to just be offset by commas).
    
                                                                Plain IPv6
                  mode (i.e., no IPv4-in-IPv6 encapsulation is used) MUST be
                  used to send PCP requests to the server.
    
    Same comment as for Section 3.2.1.
    
    Section 7
    
                                                               However, it
       has been confirmed from existing open source implementations
       (OpenWRT/LEDE, Linux, others), that adding the support for the new
       transitions mechanisms, requires around 10-12 Kbytes (because most of
       the code base is shared among several transition mechanisms already
       supported by [RFC7084]), as a single data plane is common to all
       them, which typically means about 0,15% of the existing code size in
       popular CEs already in the market [OpenWRT].
    
    nit: This sentence is very long.  Even if it is not split into smaller
    sentences for clarity, I would suggest at least clarifying that the 0,15%
    refers to 10-12 KB being 0.15% of the existing code size.
    
       In general, the new requirements don't have extra cost in terms of
       RAM memory, neither other hardware requirements such as more powerful
       CPUs, if compared to the cost of NAT44 code so, existing hardware
       supports them with minimal impact.
    
    nit: s/neither/nor/; s/ so,/, so/; s/supports them/should be able to
    support them/.
    
       Finally, in some cases, operators supporting several transition
       mechanisms may need to consider training costs for staff in all those
       techniques for their operation and management, even if this is not
    
    nit: I don't think "those" is the right word here; maybe "the"?
    
    Section 8
    
    I agree with the secdir reviewer that it would be pretty easy to include
    some more discussion of the DHCP (in)security situation in some common
    network types that would be relevant for this document, e.g., giving some
    guidance that for residential networks the risk/reward is likely in favor
    of trusting the information in DHCP responses even without DHCP security.
    
    Section 11
    
       The situation previously described, where there is ongoing IPv6
       deployment and lack of IPv4 addresses, is not happening at the same
       pace in every country, and even within every country, every ISP.  For
    
    nit: "for every ISP"
    
       the global transition timings cannot be estimated.
    
    nit: they can be estimated by anyone with a pulse; what cannot be done is
    reliable estimation.
    
       Considering that situation and different possible usage cases, the
       IPv6 Transition CE Router described in this document is expected to
       be used typically, in residential/household, Small Office/Home Office
       (SOHO) and Small/Medium Enterprise (SME).  [...]
    
    I share the concern expressed in the directorate review of the use of the
    term "SME" here (but did not yet get a chance to fully follow the
    subsequent discussion).
    
       The above is not intended to be comprehensive list of all the
       possible usage cases, just an overall view.  In fact, combinations of
    
    nit: "a comprehensive"
    
       the above usages are also possible, as well as situations where the
       same CE is used at different times in different scenarios or even
       different services providers that may use a different transition
       mechanism.
    
    nit: "or even with different"
    
      available in any IPv6 router, when using GUA (IPv6 Global Unicast
    
    nit: no comma here
    
       Addresses), unless they are blocked by firewall rules, which may
       require some manual configuration by means of a GUI, CLI and/or API.
    
    same comment as above -- can't we just say "manual configuration" and not
    guess at modes of doing so?
    
       already provide a GUI and/or a CLI to manually configure them, or the
       possibility to setup the CE in bridge mode, so another CE behind it,
       takes care of that.  The requirements for that support are out of the
    
    nit: no comma before "takes care of that"
    
       It is not relevant who provides the IPv6 Transition CE Router.  In
       most of the cases is the service provider, and in fact is
       responsible, typically, of provisioning/managing at least the WAN
    
    nit: "it is the service provider"
    nit: "in fact they are responsible, typically, for provisioning/managing"
    
       underscores the importance of the IPv6 Transition CE Routers
       supporting the same requirements defined in this document.
    
    nit: generally I see "supporting" with "features" and "meeting" or
    "fulfilling" with "requirements".
    
    Section 12
    
       combined with a dynamic routing protocol.  Once again, this is true
       for both, IPv4 and IPv6.
    
    nit: no comma here
    
    
    _______________________________________________
    v6ops mailing list
    [e-mail]
    https://www.ietf.org/mailman/listinfo/v6ops
    



**********************************************
IPv4 is over
Are you ready for the new Internet ?
http://www.theipv6company.com
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.