Hi Shu, all,
Please see inline.
Cheers,
Med
De : Softwires [mailto:softwires-boun...@ietf.org] De la part de ??
Envoyé : dimanche 2 juin 2019 17:30
À : Benjamin Kaduk; The IESG
Cc : softwires; draft-ietf-softwire-mesh-multicast; softwire-chairs
Objet : Re: [Softwires] Benjamin Kaduk's No
Hi, Shu,
> On Jun 2, 2019, at 8:31 AM, 杨术 wrote:
>
> Dear Joseph,
>
> Thank you for your comments.
>
> About fragmentation, we modified this part as following:
>
> The encapsulation performed by an upstream AFBR will increase the
>size of packets. As a result, the outgoing I-IP link MTU
Dear Mirja,
Thank you for your comments!
> On section 7.3: Thanks for discussing fragmentation and pointing to
> [I-D.ietf-intarea-tunnels]. As [I-D.ietf-intarea-tunnels] is still work in
> progress, I guess it could make sense to also add a reference to rfc4459
> directly. Also I don't think
Dear Joseph,
Thank you for your comments.
About fragmentation, we modified this part as following:
The encapsulation performed by an upstream AFBR will increase thesize of
packets. As a result, the outgoing I-IP link MTU may notaccommodate the
larger packet size. It is not
Dear Alvaro,
Thank you for your detailed comments,
(1) §5.4 mentions an "IPv4-Embedded IPv6 Virtual Source Address Format". Even
though source address mapping had just been discussed (§5.3), it wasn't clear
right away that you were talking about the same thing. Maybe it was the
Dear Alexey,
Thank you for your comments,
> 1) "COULD" is not one of RFC 2119 keywords, so it shouldn't be uppercased in
> order to avoid causing confusion for readers.
We make all “COULD” lowercased.
> 2) In Section 10 the document says:
>> Compared with [RFC4925],
Dear Alissa,
Thank you for your helpful comment, we reply as following,
> NEW
> Fragmentation and tunnel configuration considerations are provided in
> [RFC4459]
> and [I-D.ietf-intarea-tunnels].
Based on your comment, and comments from Joe,
> However, it cites RFC 5565, which cites
Dear Ben,
Thank you for your comments, we reply as following,
> §2: Please use the boilerplate from RFC 8174.
We have replaced RFC 2119 with RFC 8174.
> §10: "... the security concerns SHOULD be considered more carefully...":
> That seems more a statement of fact than a
Dear Benjamin,
Thank you for your helpful and detailed comments, we reply as following,
> Section 1
> I think you should provide a brief summary of what "(S,G) states" are in
> this document, as well as the reference.
We added the text “(S,G) states, which is source specific
