Subject: [v6ops] Mirja Kühlewind's No Objection on draft-ietf-v6ops-transition-ipv4aas-12: (with COMMENT)

From: Mirja Kühlewind <[email-masked]>
Date: Wed, 09 Jan 2019 08:32:49 -0800

Mirja Kühlewind 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:
----------------------------------------------------------------------

Some more processing-related comments:

1) "The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document, are not used as described in RFC 2119 [RFC2119]."
While it is not forbidden to define their own language requirements, I find
this really confusing. I've seen that RFC7084 uses the same definition but
actually I don't think the usage is really that different. I'd say the keywords
are used in a similar fashion in other informational docs.

2) In the abstract:
"this document extends the "Basic Requirements for IPv6
   Customer Edge Routers" (RFC7084) in order to allow the provisioning
   of IPv6 transition services for the support of "IPv4 as-a-Service"
   (IPv4aaS) by means of new transition mechanisms."
Shouldn't this doc maybe actually update RFC7084 then? Otherwise,how is someone
reading RFC7084 supposed to know about this RFC as well?

---

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Wed, 09 Jan 2019 19:06:16 +0100

Hi Mirja,

I'm happy using or not RFC2119, but this work started as an update of RFC7084, we just used the same way. I fully agree that basically the intent is the same, but this part of the text may explain it:
" This
   document uses these keywords not strictly for the purpose of
   interoperability, but rather for the purpose of establishing
   industry-common baseline functionality."

Regarding updating RFC7084, as said, it was my original intent, we had very long debates in the WG about that, and the decision was finally not going into that direction, because lots of RFI/RFQs are based on RFC7084, etc.

Also, the difference is RFC7084 only takes care of "must support IPv6" (anything related to transition is optional), and here the intent is to make sure that new CEs support IPv4aaS.

Regards,
Jordi

-----Mensaje original-----
De: v6ops <[email-masked]> en nombre de Mirja Kühlewind <[email-masked]>
Fecha: miércoles, 9 de enero de 2019, 17:33
Para: The IESG <[email-masked]>
CC: <[email-masked]>, <[email-masked]>, <[email-masked]>
Asunto: [v6ops] Mirja Kühlewind's No Objection on draft-ietf-v6ops-transition-ipv4aas-12: (with COMMENT)

    

    
    2) In the abstract:

    _______________________________________________
    v6ops mailing list
    [email-masked]
    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.