Subject: Re: [Gen-art] Gen-ART review of draft-ietf-v6ops-siit-dc-2xlat-01

From: Tore Anderson <[email-masked]>
Date: Wed, 7 Oct 2015 11:54:07 +0200

Hi again Christer, and thanks again for reviewing!

* Christer Holmberg <[email-masked]>

> Section 2 (Terminology):
> ------------------------------
> 
> Q2_1: Many of the definitions have been defined in
> draft-ietf-v6ops-siit-dc. Now they are re-defined, and sometimes with
> a little different wording.
> 
> For those definitions, my suggestion would be to say:
> 
> "As defined in [draft-ietf-v6ops-siit-dc], a XXX is a blah blah blah"
> - copy/pasting the text from draft-ietf-v6ops-siit-dc.

Ack. I simply copied the definitions from -siit-dc (without the "As
defined in..." prefix you proposed, since I think it would be rather
repetitive).

The only definition that is not identical between -siit-dc and
-siit-dc-2xlat now is the ER one; the [draft-ietf-v6ops-siit-dc-2xlat]
reference is removed in -siit-dc-2xlat, instead your Q2_2 suggestion is
added. Hope that's fine.

> Q2_2: In the Edge Relay, I think it would be good to mention the two
> types (node-based and network-based).

Fixed. References to the appropriate sections defining the two variants
also added.

> Section 4 (Deployment Considerations):
> ---------------------------------------------------
> 
> Q4_1:
> 
> The text in section 4.1. says:
> 
>                              "The IPv6 Path MTU between the ER and
> the BR will typically be larger than the default value defined in
> Section 4 of [RFC6145] (1280),"
> 
> What is (1280)?

Bytes. Fixed.

> Section 5 (Intra-IDC IPv4 Communication):
> ---------------------------------------------------
> 
> Q5_1:
> 
> The text in section 5.1 says:
> 
> "If the BR supports hairpinning as described in Section 4.2 of I-D
>    .ietf-v6ops-siit-eam [I-D.ietf-v6ops-siit-eam],"
> 
> I suggest to remove I-D.ietf-v6ops-siit-eam. The reference is enough.

Fixed.

> Section 7 (IANA Considerations):
> ----------------------------------------
> 
> Q7_1: Do we normally remove the section if there are no requests from
> IANA? Personally I prefer to keep the explicit "This draft makes no
> request of the IANA." sentence.

Fixed.

> Section 8 (Security Considerations):
> ----------------------------------------
> 
> Q8_1:
> 
> The text says:
> 
> "See the Security Considerations section in
>    [I-D.ietf-v6ops-siit-dc] for additional security considerations
>    applicable to the SIIT-DC architecture in general."
> 
> I suggest to remove "additional".

Fixed.

> Q8_2:
> 
> Is there a need to have section 8.1, or can all text be put in
> section 8?

I supposed not. Fixed.

The changes implemented can be seen here:

https://github.com/toreanderson/ietf/commit/c22ca60c39eb0d98506ce7bae252cf5327be6acf

Please have a look and let me know if further changes are required, in
your opinion. Thanks again!

Best regards,
Tore Anderson

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 8 Oct 2015 10:51:51 +0000

Hi Tore,

I am happy with your suggestions on how to address my comments :)

Thanks!

Regards,

Christer

-----Original Message-----
From: Tore Anderson [mailto:[email-masked]] 
Sent: 7. lokakuuta 2015 12:54
To: Christer Holmberg
Cc: [email-masked]; [email-masked]
Subject: Re: Gen-ART review of draft-ietf-v6ops-siit-dc-2xlat-01

> Section 2 (Terminology):

Ack. I simply copied the definitions from -siit-dc (without the "As defined in..." prefix you proposed, since I think it would be rather repetitive).

The only definition that is not identical between -siit-dc and -siit-dc-2xlat now is the ER one; the [draft-ietf-v6ops-siit-dc-2xlat] reference is removed in -siit-dc-2xlat, instead your Q2_2 suggestion is added. Hope that's fine.

> types (node-based and network-based).

Fixed. References to the appropriate sections defining the two variants also added.

>                              "The IPv6 Path MTU between the ER and the 
> BR will typically be larger than the default value defined in Section 
> 4 of [RFC6145] (1280),"
> 
> What is (1280)?

Bytes. Fixed.

Fixed.

Fixed.

Fixed.

> Q8_2:
> 
> Is there a need to have section 8.1, or can all text be put in section 
> 8?

I supposed not. Fixed.

Please have a look and let me know if further changes are required, in your opinion. Thanks again!

Best regards,
Tore Anderson

---

From: Jari Arkko <[email-masked]>
Date: Thu, 15 Oct 2015 10:20:36 +0300

Thanks for your review, Christer!

(For information, a fair number of I-Ds say that an empty IANA considerations section should be removed by the RFC Editor. Either way is fine.)

Jari