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

[[e-mail]]

Hi Mirja,

Thanks for your comments. Please see inline below.

Regards,
Ian

> On 7. Jan 2019, at 18:06, Mirja Kühlewind <[e-mail]> wrote:
> 
> 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…?

[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]).
]


> 
> 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?

[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
> unified.

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

Number of IPv4 packets received.
]
> 
>