Subject: [Softwires] Mirja Kühlewind's No Objection on draft-ietf-softwire-yang-14: (with COMMENT)

From: Mirja Kühlewind <[email-masked]>
Date: Mon, 07 Jan 2019 09:06:48 -0800

Mirja Kühlewind has entered the following ballot position for
draft-ietf-softwire-yang-14: 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-softwire-yang/

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

Some minor comments:

1) Sec 4.2:
"softwire-path-mru: optionally used to set the maximum IPv6
      softwire packet size that can be received, including the
      encapsulation/translation overhead.  Needed if the softwire
      implementation is unable to correctly calculate the correct IPv4
      Maximum Receive Unit (MRU) size automatically [RFC4213]."
I guess this should both be IPv6...?

2) Why does the description of "rcvd-ipv4-bytes" say
"IPv4 traffic received for processing, in bytes"..?
Does the "for processing" have any special meaning or why is it only phrased
like this for that one entry?

3) Also the description for "sent-ipv4-bytes" and "sent-ipv4-packets" could be
unified.

---

From: [email-masked]
Date: Wed, 9 Jan 2019 17:15:32 +0100

Hi Mirja,

Thanks for your comments. Please see inline below.

Regards,
Ian

> On 7. Jan 2019, at 18:06, Mirja Kühlewind <[email-masked]> wrote:
> 
> I guess this should both be IPv6…?

[if - This parameter is provided to address the possible fragmentation
problems described in RFC4213 section 3.2, where the sender is sending
encapsulated packets based on the IPv6 MTU resulting in the receiver
getting IPv4 payloads larger than they can process, or requiring the IPv4
to be fragmented, so the second IPv4 is correct.

Would the following wording for the second sentence make this more clear?:

Needed if the softwire implementation is unable to correctly
calculate the correct IPv4 payload Maximum Receive Unit (MRU)
size automatically (see Section 3.2 of [RFC4213]).
]

> like this for that one entry?

[if - No special meaning is intended. Will reword with:

IPv4 traffic received, in bytes.
]

> 3) Also the description for "sent-ipv4-bytes" and "sent-ipv4-packets" could be

[if - Will reword the rcvd-ipv4-packets description (also aligned with the rcvd-ipv6-packets
description:

Number of IPv4 packets received.
]