[Softwires] Adam Roach's No Objection on draft-ietf-softwire-yang-14: (with COMMENT)

[Adam Roach]

Adam Roach 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:
--

I support Alissa's discuss.

Further to Benjamin's discuss, I note that the YANG modules in this document
indicate two editors (I. Farrer and M. Bocadair) and five authors. Assuming
this distinction is intentional, RFC 7322 points to a clear resolution:

   If there is a
   request for more than five authors, the stream-approving body needs
   to consider if one or two editors should have primary responsibility
   for this document, with the other individuals listed in the
   Contributors or Acknowledgements section.

Based on the RFC 7322 text, I suspect that the best approach is moving the
five non-editors to a "Contributors" section.


___
Softwires mailing list
Softwires@ietf.org
https://www.ietf.org/mailman/listinfo/softwires

[Softwires] Ben Campbell's No Objection on draft-ietf-softwire-yang-14: (with COMMENT)

[Ben Campbell]

Ben Campbell 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:
--

I support Alissa's DISCUSS.

I share Benjamin's question about the number of authors.


___
Softwires mailing list
Softwires@ietf.org
https://www.ietf.org/mailman/listinfo/softwires

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

[ianfarrer]

Hi Mirja,

Thanks for your comments. Please see inline below.

Regards,
Ian

> On 7. Jan 2019, at 18:06, Mirja Kühlewind  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.
]
> 
> 

___
Softwires mailing list
Softwires@ietf.org
https://www.ietf.org/mailman/listinfo/softwires