Re: [v6ops] Ben Campbell's No Objection on draft-ietf-v6ops-transition-ipv4aas-12: (with COMMENT)

Hi Ben,

There has been long discussion in the WG about updating RFC7084. Initially this document was RFC7084-bis and accepted as WG item (https://datatracker.ietf.org/doc/draft-ietf-v6ops-rfc7084-bis/), but then it was decided to make it an independent document.

Regarding RFC2119/8174 usage, I've already provided in previous comments my opinion on that. I will be fine to use that boilerplate if this is an issue, but we clearly state that it is a special language, following RFC7084, as we are trying to make both documents "coherent".

I will submit a new version in an hour or so, including the last agreed (in v6ops) as a result of the security-area review by Christian Huitema for the security section changes which I think also resolves your last comment.

I'm going to try to take the opportunity to tidy up the sentences that you commented so they are more "parseable".

Thanks!

Regards,
Jordi

-----Mensaje original-----
De: v6ops <v6ops-bounces@ietf.org> en nombre de Ben Campbell <ben@nostrum.com>
Fecha: miércoles, 9 de enero de 2019, 23:17
Para: The IESG <iesg@ietf.org>
CC: <draft-ietf-v6ops-transition-ipv4aas@ietf.org>, <v6ops-chairs@ietf.org>, <v6ops@ietf.org>
Asunto: [v6ops] Ben Campbell's No Objection on draft-ietf-v6ops-transition-ipv4aas-12: (with COMMENT)

    Ben Campbell has entered the following ballot position for
    draft-ietf-v6ops-transition-ipv4aas-12: No Objection

    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/

    ----------------------------------------------------------------------
    COMMENT:
    ----------------------------------------------------------------------

    General: I'm curious why this is not a BCP. The shepherd review states that it
    doesn't recommend practices, but that seems to be me to be exactly what it does.

    abstract: Does this need to update RFC7084?

    §1, 2nd paragraph: The paragraph does not parse.

    §1.1: Is there a reason not to use the updated boilerplate from RFC 8174?

    §3.2, third paragraph: The paragraph is hard to follow. Please consider
    breaking into simpler sentences.

    §3.2.1: "The IPv6 Transition CE Router MUST support CLAT functionality
    [RFC6877] if intended for the retail market. If 464XLAT is
    supported, it MUST be implemented according to [RFC6877]."
    The 2nd MUST seems redundant; we don't generally need to say that a function
    defined in an RFC MUST be implemented according to that RFC unless there's some
    reason to expect people might do otherwise.

    §7:
    - The entirety of this section is very hard to parse.

    - "... only integration and testing cost may become a minor issue."
    I don't think that's a judgement the IETF is in a position to make. It's not
    all that unusual for integration and testing to be greater costs than coding.

    §8, 2nd paragraph: Is there any guidance that can be given for mitigating this
    issue in the context of transition mechanisms?

    _______________________________________________
    v6ops mailing list
    v6ops@ietf.org
    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.