Re: [Gen-art] Gen-ART Last Call review of draft-ietf-softwire-map-dhcp-08

>> We may add a sentence states that “It is an invalid option, if received by >> server, discard.” > > Please do not add such a sentence. Rather, please add a sentence that says: > > This option has no meaning when sent from client to server. However, servers > may take options sent by clien

Re: [Gen-art] Gen-ART Last Call review of draft-ietf-softwire-map-dhcp-08

Brian, >> Anyway, I'm fine with either way. > > So am I, really, as long as the people involved have thought about it. > You might prefer the references to be RFCs rather than "work in progress" > though; if you make them normative, that will be the result. there is a lot of history here. these

Re: [Gen-art] Gen-ART Last Call review of draft-ietf-softwire-map-dhcp-08

Brian, thank you very much for a thorough review. combined with Ted's AD review there are quite a few changes. can you look over the attached diffs, and let us know if that is acceptable? I've tried to combine the suggestions made by Ian and Congxiao. Best regards, Ole diff --git a/draft-ietf-so

Re: [Gen-art] Gen-ART Last Call review of draft-ietf-softwire-map-dhcp-08

> > Agree to unify the terminology. We may add a “Terminology section” similar to > the ones in [I-D.ietf-softwire-map] (Section 3). would something like: This document describes a set of common DHCPv6 options for configuring the MAP-E [I-D.ietf-softwire-map], MAP-T [I-D.ietf-softwire-

Re: [Gen-art] review of draft-ietf-softwire-map-10.txt

Francis, thank you very much for the thorough review! comments inline. > I am the assigned Gen-ART reviewer for this draft. For background on > Gen-ART, please see the FAQ at > > . > > Please resolve these comments along with any other La

Re: [Gen-art] Gen-ART Last Call review of draft-ietf-6man-resilient-rs-04

Brian, thank you very much for the review. > I am the assigned Gen-ART reviewer for this draft. For background on > Gen-ART, please see the FAQ at > . > > Please resolve these comments along with any other Last Call comments > you may rece

Re: [Gen-art] Gen-ART Last Call review of draft-ietf-6man-resilient-rs-04

Suresh, Brian, >>> >>> Minor issues: >>> - >>> >>> The writeup says "There was significant discussion if this document >>> should be extended to support links without multicast RAs >>> altogether. The consensus in the WG was to not do that in this >>> document." >>> >>> But the Abst

Re: [Gen-art] Genart telechat review of draft-ietf-6man-ndpioiana-02

Hi Dan, Thank you very much for the thorough review. Apologies for the delay. Procrastination and holiday came in the way. See below. > Reviewer: Dan Romascanu > Review result: Almost Ready > > I am the assigned Gen-ART reviewer for this draft. The General Area > Review Team (Gen-ART) reviews a

Re: [Gen-art] Genart telechat review of draft-ietf-6man-ndpioiana-02

Brian, >>> 4. Section 4 - It would be good to capitalize Standards Action, and refer to >>> RFC 8126 as reference (also to be added) >> >> Capitalisation done. >> I ended up leaning towards not referencing 8126. As most documents with IANA >> considerations don't. To be consistent. > > Really?

Re: [Gen-art] [Softwires] Genart last call review of draft-ietf-softwire-mesh-multicast-22

> No, it isn't, but as far as I can see, any tunnel spec needs to state how > this applies. If the tunnel keeps no packet state, how is it going to perform > PMTUD? If the answer is that the tunnel end points need to be configured in > some way, that needs to be stated too. > > Sorry to go on,

Re: [Gen-art] Gen-ART LC Review of draft-ietf-v6ops-6to4-to-historic-04

Ben, splendid comments! I've tried to incorporate all of them, and will either issue a new revision or make the changes during AUTH48 depending on other LC feedback. cheers, Ole > I am the assigned Gen-ART reviewer for this draft. For background on Gen-ART, > please see the FAQ at >

Re: [Gen-art] [Last-Call] Genart last call review of draft-ietf-v6ops-slaac-renum-03

> On 3 Sep 2020, at 11:03, Owen DeLong wrote: > > A network which does not support SLAAC will likely not have PIOs in its RAs. > If a PIO is present, its sole purpose is to provide information about a > prefix which may be considered by SLAAC (though the PIO may indicate that the > prefix in q