Re: [Gen-art] Gen-art LC review of draft-ietf-dmm-best-practices-gap-analysis-07

2014-10-10 Thread H Anthony Chan
Elwyn, Thank you for your review. We have revised and uploaded version -08 with the following changes: Applicability to Mobile IPv4? It appears from the early sections that this draft is pretty much concentrated on Mobile IPv6 (see the first para of s3 which mentions v6 RFCs exclusively and I

[Gen-art] Gen-ART Telechat Call review of draft-ietf-uta-tls-attacks-04

2014-10-10 Thread Meral Shirazipour
I am the assigned Gen-ART reviewer for this draft. For background on Gen-ART, please see the FAQ at . Please wait for direction from your document shepherd or AD before posting a new version of the draft. Document: draft-ietf-uta-tls-atta

[Gen-art] Gen-ART Last Call review of draft-ietf-uta-tls-attacks-04

2014-10-10 Thread Meral Shirazipour
I am the assigned Gen-ART reviewer for this draft. For background on Gen-ART, please see the FAQ at http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq. Please resolve these comments along with any other Last Call comments you may receive. Document: draft-ietf-uta-tls-attacks-04 Reviewer: M

[Gen-art] Gen-ART Telechat Call review of draft-ietf-oauth-saml2-bearer-21

2014-10-10 Thread Meral Shirazipour
I am the assigned Gen-ART reviewer for this draft. For background on Gen-ART, please see the FAQ at < http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>. Please wait for direction from your document shepherd or AD before posting a new version of the draft. Document: draft-ietf-oauth-saml

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

2014-10-10 Thread Ole Troan
> > 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] Gen-ART Last Call review of draft-ietf-softwire-map-dhcp-08

2014-10-10 Thread Ole Troan
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

2014-10-10 Thread Ted Lemon
On Oct 10, 2014, at 3:03 PM, Tomek Mrugalski wrote: > This option follows behavior described in Sections 17.1.1 > and 18.1.1 of RFC3315. Clients can insert > those options with specific values as hints for the > server. Depending on the server configuration and policy, > it may accept or

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

2014-10-10 Thread Tomek Mrugalski
On 10/10/14 21:01, Brian E Carpenter wrote: > Hi, > > I believe I'm happy with all this. I am supposed to repeat > my Gen-ART review immediately, for the imminent IESG meeting. > If you get the -09 draft out promptly that would be great. Sure. Will do that in the next 24 hours. _

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

2014-10-10 Thread Tomek Mrugalski
On 10/10/14 16:42, Ted Lemon wrote: > On Oct 10, 2014, at 4:36 AM, Ole Troan wrote: >> hmm. that's actually an interesting point. does it harm to allow >> this to be a hint to the server? if that how DHCP servers generally >> work? > > The problem is that the client might supply a wrong hint. I

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

2014-10-10 Thread Brian E Carpenter
Hi, I believe I'm happy with all this. I am supposed to repeat my Gen-ART review immediately, for the imminent IESG meeting. If you get the -09 draft out promptly that would be great. Regards Brian On 10/10/2014 21:53, Ole Troan wrote: > Brian, > > thank you very much for a thorough review.

[Gen-art] second/independent view on draft-ietf-softwire-map-10.txt

2014-10-10 Thread Francis Dupont
I reviewed the draft-ietf-softwire-map-10.txt document but I was too involved in Softwire stuff to be able to judge whether the text is understable without prior knowledge. Can someone from the team look at it and summary in the list? Thanks francis.dup...@fdupont.fr

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

2014-10-10 Thread Francis Dupont
viewer: Francis Dupont Review Date: 20141009 IETF LC End Date: 20141010 IESG Telechat date: 20141016 Summary: Ready Major issues: None Minor issues: None Nits/editorial comments: First please note I participated to Softwire WG work so it is possible the document is not understantable by someo

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

2014-10-10 Thread Ted Lemon
On Oct 10, 2014, at 4:36 AM, Ole Troan wrote: > hmm. that's actually an interesting point. does it harm to allow this to be a > hint to the server? > if that how DHCP servers generally work? The problem is that the client might supply a wrong hint. I am not aware of any DHCP servers that actu

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

2014-10-10 Thread Tomek Mrugalski
On 10/10/14 10:36, Ole Troan wrote: >>> 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,

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

2014-10-10 Thread Ole Troan
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

2014-10-10 Thread Ole Troan
>> 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