Re: [Gen-art] Resolution on comments of draft-ietf-l2vpn-vpls-pe-etree-10

[Jiangyuanlong]

Ben,

Thanks for your confirmation. Yes, it is still unsubmitted.
We plan to post the new version this week.

Cheers,
Yuanlong

> -Original Message-
> From: Ben Campbell [mailto:b...@nostrum.com]
> Sent: Tuesday, December 15, 2015 6:48 AM
> To: Jiangyuanlong
> Cc: Russ Housley; Stephen Farrell; Jari Arkko; Sheng Jiang; Barry Leiba; 
> Alvaro
> Retana; Stewart Bryant; draft-ietf-l2vpn-vpls-pe-etree@ietf.org; IETF 
> Gen-ART;
> The IESG; BRUNGARD, DEBORAH A
> Subject: Re: Resolution on comments of draft-ietf-l2vpn-vpls-pe-etree-10
> 
> Hi,
> 
> This (I assume still unsubmitted) version addresses my IESG ballot
> comments.
> 
> Thanks!
> 
> Ben.
> 
> On 11 Dec 2015, at 5:16, Jiangyuanlong wrote:
> 
> > Hi all,
> >
> > Thanks a lot for your reviews.
> > Based on all the comments received during the IESG evaluation, we have
> > prepared a tentative version 11 for this draft.
> > We believe all the comments are resolved, but please check whether you
> > have any concerns with the texts in this version.
> >
> > If there are no further comments, we will upload it as the formal
> > revision 11 version.
> >
> > Best regards,
> > Yuanlong
> >
> >> -Original Message-
> >> From: BRUNGARD, DEBORAH A [mailto:db3...@att.com]
> >> Sent: Thursday, December 03, 2015 11:03 PM
> >> To: Jari Arkko
> >> Cc: Jiangyuanlong; Russ Housley;
> >> draft-ietf-l2vpn-vpls-pe-etree@ietf.org; IETF
> >> Gen-ART; IETF
> >> Subject: Re: [Gen-art] Gen-ART Review of
> >> draft-ietf-l2vpn-vpls-pe-etree-10
> >>
> >> Hi Jari,
> >>
> >> Yes, we'll be doing a new revision for addressing other comments.
> >>
> >> I've asked for today's telechat if no discusses to mark it as
> >> approved, revised
> >> draft needed.
> >>
> >> Much thanks Russ for your review!
> >>
> >> Deborah
> >>
> >>
> >> Sent from my iPhone
> >>
> >>> On Dec 3, 2015, at 1:08 PM, Jari Arkko  wrote:
> >>>
> >>> Many thanks for your detailed review, Russ!
> >>>
> >>> Yuanlong, will there be a new draft version or other edits before
> >>> the draft
> >>> is approved?
> >>>
> >>> Jari
> >>>
>  On 17 Nov 2015, at 00:53, Jiangyuanlong 
> >> wrote:
> 
>  Russ,
> 
>  Thanks a lot for your review and good observations.
>  Please see my comments in line.
> 
>  Best regards,
>  Yuanlong
> 
> > -Original Message-
> > From: Russ Housley [mailto:hous...@vigilsec.com]
> > Sent: Saturday, November 14, 2015 1:28 AM
> > To: draft-ietf-l2vpn-vpls-pe-etree@ietf.org
> > Cc: IETF Gen-ART; IETF
> > Subject: Gen-ART Review of draft-ietf-l2vpn-vpls-pe-etree-10
> >
> > I am the assigned Gen-ART reviewer for this draft. The General
> > Area Review
> > Team (Gen-ART) reviews all IETF documents being processed by the
> > IESG for
> > the IETF Chair. Please wait for direction from your document
> > shepherd or AD
> > before posting a new version of the draft.
> >
> > For more information, please see the FAQ at
> > .
> >
> > Document: draft-ietf-l2vpn-vpls-pe-etree-10
> > Reviewer: Russ Housley
> > Review Date: 2015-11-13
> > IETF LC End Date: 2015-11-24
> > IESG Telechat date: unknown
> >
> > Summary:  Almost Ready
> >
> >
> > Major Concerns: None
> >
> >
> > Minor Concerns:
> >
> > Sections 4.1 and 5.3.1 inclues a reference to [802.1Q-2011].
> > Should this be
> > the 2014 version of the document?  If not, please add the
> > informative
> > reference for [802.1Q-2011].
>  [YJ] Yes, all these should refer to [802.1Q-2014].
> 
> >
> > Other Editorial Comments:
> >
> > The Abstract should appear on the title page.
>  [YJ] OK.
> 
> > Section 3 needs a reference for MEF 6.1:
> > s/Specification MEF 6.1/Specification MEF 6.1 [MEF6.1]/ Also,
> > [MEF6.1]
> > needs to be added as a normative reference.
>  [YJ] All these will be updated to MEF 6.2.
> 
> > Section 3 needs a reference for IEEE 802.1Q-2003:
> > s/B.1.3 of IEEE 802.1Q-2003/B.1.3 of IEEE 802.1Q-2003
> > [802.1Q-2003]/ Also,
> > please add an informative reference for [802.1Q-2003].
>  [YJ] Yes, we will add an informative reference for [802.1Q-2003].
> 
> > Third level section headings do not have space between the section
> > number
> > and the section title.  For example:
> > s/5.3.1.PW Processing/5.3.1. PW Processing/
>  [YJ] OK.
> 
> > In Fig 4, there is room to shift the figure to the right, this
> > will allow the "AC"
> > labels to fit better on the left:
> >
> >  ++
> >  |   VPLS-capable PE model|
> >  |   +---+  +--+  |
> >  |   |   |==|TVSI-1|
> > 

Re: [Gen-art] Resolution on comments of draft-ietf-l2vpn-vpls-pe-etree-10

[Sheng Jiang]

Hi, I can confirm this version addresses my OPS DIR review comments.

Thanks,

Sheng

>-Original Message-
>From: Jiangyuanlong
>Sent: Friday, December 11, 2015 7:17 PM
>To: Russ Housley; Stephen Farrell; Jari Arkko; Sheng Jiang; Ben Campbell; Barry
>Leiba; Alvaro Retana (aretana); Stewart Bryant
>Cc: draft-ietf-l2vpn-vpls-pe-etree@ietf.org; IETF Gen-ART; The IESG;
>BRUNGARD, DEBORAH A
>Subject: Resolution on comments of draft-ietf-l2vpn-vpls-pe-etree-10
>
>Hi all,
>
>Thanks a lot for your reviews.
>Based on all the comments received during the IESG evaluation, we have
>prepared a tentative version 11 for this draft.
>We believe all the comments are resolved, but please check whether you have
>any concerns with the texts in this version.
>
>If there are no further comments, we will upload it as the formal revision 11
>version.
>
>Best regards,
>Yuanlong
>
>> -Original Message-
>> From: BRUNGARD, DEBORAH A [mailto:db3...@att.com]
>> Sent: Thursday, December 03, 2015 11:03 PM
>> To: Jari Arkko
>> Cc: Jiangyuanlong; Russ Housley; draft-ietf-l2vpn-vpls-pe-etree@ietf.org;
>IETF
>> Gen-ART; IETF
>> Subject: Re: [Gen-art] Gen-ART Review of draft-ietf-l2vpn-vpls-pe-etree-10
>>
>> Hi Jari,
>>
>> Yes, we'll be doing a new revision for addressing other comments.
>>
>> I've asked for today's telechat if no discusses to mark it as approved, 
>> revised
>> draft needed.
>>
>> Much thanks Russ for your review!
>>
>> Deborah
>>
>>
>> Sent from my iPhone
>>
>> > On Dec 3, 2015, at 1:08 PM, Jari Arkko  wrote:
>> >
>> > Many thanks for your detailed review, Russ!
>> >
>> > Yuanlong, will there be a new draft version or other edits before the draft
>> > is approved?
>> >
>> > Jari
>> >
>> >> On 17 Nov 2015, at 00:53, Jiangyuanlong 
>> wrote:
>> >>
>> >> Russ,
>> >>
>> >> Thanks a lot for your review and good observations.
>> >> Please see my comments in line.
>> >>
>> >> Best regards,
>> >> Yuanlong
>> >>
>> >>> -Original Message-
>> >>> From: Russ Housley [mailto:hous...@vigilsec.com]
>> >>> Sent: Saturday, November 14, 2015 1:28 AM
>> >>> To: draft-ietf-l2vpn-vpls-pe-etree@ietf.org
>> >>> Cc: IETF Gen-ART; IETF
>> >>> Subject: Gen-ART Review of draft-ietf-l2vpn-vpls-pe-etree-10
>> >>>
>> >>> I am the assigned Gen-ART reviewer for this draft. The General Area
>Review
>> >>> Team (Gen-ART) reviews all IETF documents being processed by the
>IESG for
>> >>> the IETF Chair. Please wait for direction from your document shepherd
>or AD
>> >>> before posting a new version of the draft.
>> >>>
>> >>> For more information, please see the FAQ at
>> >>> .
>> >>>
>> >>> Document: draft-ietf-l2vpn-vpls-pe-etree-10
>> >>> Reviewer: Russ Housley
>> >>> Review Date: 2015-11-13
>> >>> IETF LC End Date: 2015-11-24
>> >>> IESG Telechat date: unknown
>> >>>
>> >>> Summary:  Almost Ready
>> >>>
>> >>>
>> >>> Major Concerns: None
>> >>>
>> >>>
>> >>> Minor Concerns:
>> >>>
>> >>> Sections 4.1 and 5.3.1 inclues a reference to [802.1Q-2011].  Should
>this be
>> >>> the 2014 version of the document?  If not, please add the informative
>> >>> reference for [802.1Q-2011].
>> >> [YJ] Yes, all these should refer to [802.1Q-2014].
>> >>
>> >>>
>> >>> Other Editorial Comments:
>> >>>
>> >>> The Abstract should appear on the title page.
>> >> [YJ] OK.
>> >>
>> >>> Section 3 needs a reference for MEF 6.1:
>> >>> s/Specification MEF 6.1/Specification MEF 6.1 [MEF6.1]/ Also, [MEF6.1]
>> >>> needs to be added as a normative reference.
>> >> [YJ] All these will be updated to MEF 6.2.
>> >>
>> >>> Section 3 needs a reference for IEEE 802.1Q-2003:
>> >>> s/B.1.3 of IEEE 802.1Q-2003/B.1.3 of IEEE 802.1Q-2003 [802.1Q-2003]/
>Also,
>> >>> please add an informative reference for [802.1Q-2003].
>> >> [YJ] Yes, we will add an informative reference for [802.1Q-2003].
>> >>
>> >>> Third level section headings do not have space between the section
>number
>> >>> and the section title.  For example:
>> >>> s/5.3.1.PW Processing/5.3.1. PW Processing/
>> >> [YJ] OK.
>> >>
>> >>> In Fig 4, there is room to shift the figure to the right, this will 
>> >>> allow the
>"AC"
>> >>> labels to fit better on the left:
>> >>>
>> >>> ++
>> >>> |   VPLS-capable PE model|
>> >>> |   +---+  +--+  |
>> >>> |   |   |==|TVSI-1|
>> >>>  +---+  AC  |   |     | PWs
>> >>>  |CE |--| Bridge  |
>> >>>  +---+  |   |   | Root &   +--+  |
>> >>> |   | Module| Leaf VLAN   o  |
>> >>> |   |   | o  |
>> >>> |   |   | o  |
>> >>> |   |   | o  |
>> >>> |  

Re: [Gen-art] Gen-ART LC review of draft-ietf-abfab-aaa-saml-12

[Sam Hartman]

> "Klaas" == Klaas Wierenga (kwiereng)  writes:


It's also important that the new LC make a note about the normative
down-ref to RADIUS over TLS.

___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

Re: [Gen-art] Gen-ART LC review of draft-ietf-abfab-aaa-saml-12

[Stephen Farrell]

On 14/12/15 10:04, Sam Hartman wrote:
>> "Klaas" == Klaas Wierenga (kwiereng)  writes:
> 
> 
> It's also important that the new LC make a note about the normative
> down-ref to RADIUS over TLS.
> 

Good catch - thanks! ID-nits (which I'd not re-run until you reminded
me;-) didn't object to it funnily enough but I've added it to the LC
text anyway.

S.

___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

Re: [Gen-art] Gen-Art LC review: draft-ietf-jose-jws-signing-input-options-06

[Robert Sparks]

Mike -

No, this still doesn't explain why crit is not sufficient.

You are making a bare assertion that using crit doesn't achieve a). I 
think it does. Please explain (in the draft) why it doesn't.


You are making me guess, but I think you are only trying to avoid having 
to include the few extra bits in the message. If you've _done_ the work 
of ensuring all the applications understand using b64 through some 
out-of-band magic, then including crit will just work. Are you pushing 
back on anything _but_ the packet-bloat in this case?


If you _haven't_ done this out-of-band work, and you send to a receiver 
that understands the extension, then a) is achieved. If you send to a 
receiver that doesn't understand, things _should_ fail - arguably this 
also achieving a), though I suspect you are wincing at perhaps not 
having a clear path to recovery in this case?


I really think this boils down to you not wanting to pay the extra few 
bits in the packet to say "crit".
if that's not the case, please explain (and again, this needs to be in 
the draft, not just an email thread).


RjS




On 12/13/15 10:04 PM, Mike Jones wrote:

Hi Robert,

You asked "_WHY_ is crit not sufficient? I think that's the thing that's missing as 
motivation."

There are two goals we're discussing, which are related:
(a) Having an application that uses "b64":false work.
(b) Having an application that receives a JWT with "b64":false not misinterpret 
the payload content.

Including "crit":["b64"] would be sufficient to achieve (b), as it would cause the JWS to 
be rejected by implementations not supporting "b64".  But it does not achieve (a), since the JWS 
would be rejected.

In contrast, using an implementation that understands "b64" achieves both (a) and (b) 
without needing to include "crit".  That's why it's not required.

Does that make sense now?

Best wishes,
-- Mike

-Original Message-
From: Robert Sparks [mailto:rjspa...@nostrum.com]
Sent: Sunday, December 13, 2015 1:11 PM
To: Mike Jones ; General Area Review Team 
; i...@ietf.org; j...@ietf.org; 
draft-ietf-jose-jws-signing-input-opti...@ietf.org
Subject: Re: Gen-Art LC review: draft-ietf-jose-jws-signing-input-options-06

Cutting away a bit to focus on the question:

On 12/12/15 8:32 PM, Mike Jones wrote:

Hi Robert.  Thanks for the useful review.  Replies are inline below...


-Original Message-




I would have been much more comfortable with a consensus to require 'crit'.
(Count me in the rough if this proceeds with crit being optional).

I assume there is a strong reason to allow for option 1. Please add
the motivation for it to the draft, and consider adding a SHOULD use 'crit'
requirement if option 1 remains.

It's a reasonable request to have the draft say why "crit" isn't required.  My 
working draft adds the following new paragraph at the end of the security considerations 
section to do this.  Unless I hear objections, I'll plan on publishing an updated draft 
with the paragraph shortly.

"Note that methods 2 and 3 are sufficient to cause JWSs using this extension to 
be rejected by implementations not supporting this extension but they are not 
sufficient to enable JWSs using this extension to be successfully used by 
applications.

The conclusion you draw here is not at all obvious.
_WHY_ is crit not sufficient? I think that's the thing that's missing as 
motivation.


   Thus, method 1 - requiring support for this extension - is the preferred approach and the only means 
for this extension to be practically useful to applications. Method 2 - requiring the use of crit - while theoretically useful to ensure that confusion between 
encoded and unencoded payloads cannot occur, is not particularly useful in practice, since method 1 is 
still required for the extension to be usable. When method 1 is employed, method 2 doesn't add any value 
and since it increases the size of the JWS, its use is not required by this specification."


Nits/editorial comments:

In the security considerations, the last sentence of the first
paragraph needs to be simplified. I suggest replacing it with:

"It then becomes the responsibility of the application to ensure that
payloads only contain characters that will not cause parsing problems
for the serialization used, as described in Section 5. The
application also incurs the responsibility to ensure that the payload
will not be modified during retransmission.

I have simplified this in the manner that you suggested.

Thanks again,
-- Mike


___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

Re: [Gen-art] Resolution on comments of draft-ietf-l2vpn-vpls-pe-etree-10

[Jiangyuanlong]

Sheng,

Thanks much for your confirmation.

Cheers,
Yuanlong

> -Original Message-
> From: Sheng Jiang
> Sent: Tuesday, December 15, 2015 9:57 AM
> To: Jiangyuanlong; Russ Housley; Stephen Farrell; Jari Arkko; Ben Campbell; 
> Barry
> Leiba; Alvaro Retana (aretana); Stewart Bryant
> Cc: draft-ietf-l2vpn-vpls-pe-etree@ietf.org; IETF Gen-ART; The IESG;
> BRUNGARD, DEBORAH A
> Subject: RE: Resolution on comments of draft-ietf-l2vpn-vpls-pe-etree-10
> 
> Hi, I can confirm this version addresses my OPS DIR review comments.
> 
> Thanks,
> 
> Sheng
> 
> >-Original Message-
> >From: Jiangyuanlong
> >Sent: Friday, December 11, 2015 7:17 PM
> >To: Russ Housley; Stephen Farrell; Jari Arkko; Sheng Jiang; Ben Campbell; 
> >Barry
> >Leiba; Alvaro Retana (aretana); Stewart Bryant
> >Cc: draft-ietf-l2vpn-vpls-pe-etree@ietf.org; IETF Gen-ART; The IESG;
> >BRUNGARD, DEBORAH A
> >Subject: Resolution on comments of draft-ietf-l2vpn-vpls-pe-etree-10
> >
> >Hi all,
> >
> >Thanks a lot for your reviews.
> >Based on all the comments received during the IESG evaluation, we have
> >prepared a tentative version 11 for this draft.
> >We believe all the comments are resolved, but please check whether you have
> >any concerns with the texts in this version.
> >
> >If there are no further comments, we will upload it as the formal revision 11
> >version.
> >
> >Best regards,
> >Yuanlong
> >
> >> -Original Message-
> >> From: BRUNGARD, DEBORAH A [mailto:db3...@att.com]
> >> Sent: Thursday, December 03, 2015 11:03 PM
> >> To: Jari Arkko
> >> Cc: Jiangyuanlong; Russ Housley; 
> >> draft-ietf-l2vpn-vpls-pe-etree@ietf.org;
> >IETF
> >> Gen-ART; IETF
> >> Subject: Re: [Gen-art] Gen-ART Review of draft-ietf-l2vpn-vpls-pe-etree-10
> >>
> >> Hi Jari,
> >>
> >> Yes, we'll be doing a new revision for addressing other comments.
> >>
> >> I've asked for today's telechat if no discusses to mark it as approved, 
> >> revised
> >> draft needed.
> >>
> >> Much thanks Russ for your review!
> >>
> >> Deborah
> >>
> >>
> >> Sent from my iPhone
> >>
> >> > On Dec 3, 2015, at 1:08 PM, Jari Arkko  wrote:
> >> >
> >> > Many thanks for your detailed review, Russ!
> >> >
> >> > Yuanlong, will there be a new draft version or other edits before the 
> >> > draft
> >> > is approved?
> >> >
> >> > Jari
> >> >
> >> >> On 17 Nov 2015, at 00:53, Jiangyuanlong 
> >> wrote:
> >> >>
> >> >> Russ,
> >> >>
> >> >> Thanks a lot for your review and good observations.
> >> >> Please see my comments in line.
> >> >>
> >> >> Best regards,
> >> >> Yuanlong
> >> >>
> >> >>> -Original Message-
> >> >>> From: Russ Housley [mailto:hous...@vigilsec.com]
> >> >>> Sent: Saturday, November 14, 2015 1:28 AM
> >> >>> To: draft-ietf-l2vpn-vpls-pe-etree@ietf.org
> >> >>> Cc: IETF Gen-ART; IETF
> >> >>> Subject: Gen-ART Review of draft-ietf-l2vpn-vpls-pe-etree-10
> >> >>>
> >> >>> I am the assigned Gen-ART reviewer for this draft. The General Area
> >Review
> >> >>> Team (Gen-ART) reviews all IETF documents being processed by the
> >IESG for
> >> >>> the IETF Chair. Please wait for direction from your document shepherd
> >or AD
> >> >>> before posting a new version of the draft.
> >> >>>
> >> >>> For more information, please see the FAQ at
> >> >>> .
> >> >>>
> >> >>> Document: draft-ietf-l2vpn-vpls-pe-etree-10
> >> >>> Reviewer: Russ Housley
> >> >>> Review Date: 2015-11-13
> >> >>> IETF LC End Date: 2015-11-24
> >> >>> IESG Telechat date: unknown
> >> >>>
> >> >>> Summary:  Almost Ready
> >> >>>
> >> >>>
> >> >>> Major Concerns: None
> >> >>>
> >> >>>
> >> >>> Minor Concerns:
> >> >>>
> >> >>> Sections 4.1 and 5.3.1 inclues a reference to [802.1Q-2011].  Should
> >this be
> >> >>> the 2014 version of the document?  If not, please add the informative
> >> >>> reference for [802.1Q-2011].
> >> >> [YJ] Yes, all these should refer to [802.1Q-2014].
> >> >>
> >> >>>
> >> >>> Other Editorial Comments:
> >> >>>
> >> >>> The Abstract should appear on the title page.
> >> >> [YJ] OK.
> >> >>
> >> >>> Section 3 needs a reference for MEF 6.1:
> >> >>> s/Specification MEF 6.1/Specification MEF 6.1 [MEF6.1]/ Also, [MEF6.1]
> >> >>> needs to be added as a normative reference.
> >> >> [YJ] All these will be updated to MEF 6.2.
> >> >>
> >> >>> Section 3 needs a reference for IEEE 802.1Q-2003:
> >> >>> s/B.1.3 of IEEE 802.1Q-2003/B.1.3 of IEEE 802.1Q-2003 [802.1Q-2003]/
> >Also,
> >> >>> please add an informative reference for [802.1Q-2003].
> >> >> [YJ] Yes, we will add an informative reference for [802.1Q-2003].
> >> >>
> >> >>> Third level section headings do not have space between the section
> >number
> >> >>> and the section title.  For example:
> >> >>> s/5.3.1.PW Processing/5.3.1. PW Processing/
> >> >> [YJ] OK.
> >> >>
> >> >>> In Fig 4, there is room to shift the figure to the right, this will 
> >> >>> allow the
> >"AC"
> >> >>> labels to fit 

Re: [Gen-art] Gen-ART Review of draft-leiba-netmod-regpolicy-update-01

[Romascanu, Dan (Dan)]

Hi Barry,

Thanks for the quick reply and for addressing my comment. 

> Should IETF consensus be to accept a registration
> from an Informational document, that's fine.
> Perhaps it's not likely, but that'd be up to the consensus of the IETF, which 
> is
> the point here.

I am fine with this approach but this is not what the text of the 
'motivational' part of the Internet-Draft says. Currently there is an 
a-synchronism between the text that explains what the I-D tries to do and the 
action it recommends. 

Regards,

Dan


> -Original Message-
> From: barryle...@gmail.com [mailto:barryle...@gmail.com] On Behalf Of
> Barry Leiba
> Sent: Monday, December 14, 2015 4:26 PM
> To: Romascanu, Dan (Dan)
> Cc: General Area Review Team; draft-leiba-netmod-regpolicy-
> update@tools.ietf.org
> Subject: Re: Gen-ART Review of draft-leiba-netmod-regpolicy-update-01
> 
> > The problem is that the “IETF Review” policy is not restricted to
> > Experimental RFCs which seems to be the motivation of the document.
> > Informational RFCs can also be subject to IETF Review for example. The
> > IANA Considerations section does either instruct IANA to consider only
> > Standards Track and Experimental RFCs. I believe that this needs to be
> > clarified in Section 2, and the registry be marked “IETF Review – see
> > [RFC ]” so that people asking for allocation be directed to the
> clarification of the policy.
> 
> I believe that no clarification is needed.  There's no reason at all to put
> restrictions on registrations beyond what IETF consensus is at the time the
> registration is requested.  Should IETF consensus be to accept a registration
> from an Informational document, that's fine.
> Perhaps it's not likely, but that'd be up to the consensus of the IETF, which 
> is
> the point here.
> 
> The non-normative text you cite describes what prompted us to do this.
> The normative text is the description of IETF Review in BCP 26.
> 
> Barry


___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

Re: [Gen-art] Gen-ART Review of draft-leiba-netmod-regpolicy-update-01

[Romascanu, Dan (Dan)]

This looks good to me. 

Thanks and Regards,

Dan


> -Original Message-
> From: barryle...@gmail.com [mailto:barryle...@gmail.com] On Behalf Of
> Barry Leiba
> Sent: Monday, December 14, 2015 6:26 PM
> To: Romascanu, Dan (Dan)
> Cc: General Area Review Team; draft-leiba-netmod-regpolicy-
> update@tools.ietf.org
> Subject: Re: Gen-ART Review of draft-leiba-netmod-regpolicy-update-01
> 
> > I am fine with this approach but this is not what the text of the
> 'motivational' part of the Internet-Draft says. Currently there is an a-
> synchronism between the text that explains what the I-D tries to do and the
> action it recommends.
> 
> OK, well, you know I'm always in favour of more clarity.  So how does this
> sound?:
> 
> OLD
>This document changes that
>registration policy to "IETF Review", which also allows registrations
>from certain well reviewed Experimental RFCs.
> 
> NEW
>This document changes that
>registration policy to "IETF Review", which also allows registrations
>from certain well reviewed Experimental RFCs, or, for example,
>corrections to registry errors from Informational RFCs, with IETF
>review and consensus.
> 
> END
> 
> Barry
___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

Re: [Gen-art] [jose] Gen-Art LC review: draft-ietf-jose-jws-signing-input-options-06

[Jim Schaad]

Mike,

This is interesting from a couple of points.

Why would you have an application that uses "b64":false as a parameter.
This is longer and thus would appear to be undesirable from that
perspective.  It might imply that the application is using both true and
false for b64, but that is something that you have said is not recommended.

It would, of course, be perfectly acceptable to say that crit needs to be
present only if b64 is true.  This would address your worry about it failing
for the case of b64:false being included.

Jim

> -Original Message-
> From: jose [mailto:jose-boun...@ietf.org] On Behalf Of Mike Jones
> Sent: Sunday, December 13, 2015 8:05 PM
> To: Robert Sparks ; General Area Review Team  a...@ietf.org>; i...@ietf.org; j...@ietf.org;
draft-ietf-jose-jws-signing-input-
> opti...@ietf.org
> Subject: Re: [jose] Gen-Art LC review:
draft-ietf-jose-jws-signing-input-options-
> 06
> 
> Hi Robert,
> 
> You asked "_WHY_ is crit not sufficient? I think that's the thing that's
missing as
> motivation."
> 
> There are two goals we're discussing, which are related:
> (a) Having an application that uses "b64":false work.
> (b) Having an application that receives a JWT with "b64":false not
misinterpret
> the payload content.
> 
> Including "crit":["b64"] would be sufficient to achieve (b), as it would
cause the
> JWS to be rejected by implementations not supporting "b64".  But it does
not
> achieve (a), since the JWS would be rejected.
> 
> In contrast, using an implementation that understands "b64" achieves both
(a)
> and (b) without needing to include "crit".  That's why it's not required.
> 
> Does that make sense now?
> 
>   Best wishes,
>   -- Mike
> 
> -Original Message-
> From: Robert Sparks [mailto:rjspa...@nostrum.com]
> Sent: Sunday, December 13, 2015 1:11 PM
> To: Mike Jones ; General Area Review Team
> ; i...@ietf.org; j...@ietf.org;
draft-ietf-jose-jws-signing-
> input-opti...@ietf.org
> Subject: Re: Gen-Art LC review:
draft-ietf-jose-jws-signing-input-options-06
> 
> Cutting away a bit to focus on the question:
> 
> On 12/12/15 8:32 PM, Mike Jones wrote:
> > Hi Robert.  Thanks for the useful review.  Replies are inline below...
> >
> >> -Original Message-
> 
> >>
> >>
> >> I would have been much more comfortable with a consensus to require
'crit'.
> >> (Count me in the rough if this proceeds with crit being optional).
> >>
> >> I assume there is a strong reason to allow for option 1. Please add
> >> the motivation for it to the draft, and consider adding a SHOULD use
'crit'
> >> requirement if option 1 remains.
> > It's a reasonable request to have the draft say why "crit" isn't
required.  My
> working draft adds the following new paragraph at the end of the security
> considerations section to do this.  Unless I hear objections, I'll plan on
publishing
> an updated draft with the paragraph shortly.
> >
> > "Note that methods 2 and 3 are sufficient to cause JWSs using this
extension
> to be rejected by implementations not supporting this extension but they
are not
> sufficient to enable JWSs using this extension to be successfully used by
> applications.
> The conclusion you draw here is not at all obvious.
> _WHY_ is crit not sufficient? I think that's the thing that's missing as
motivation.
> 
> >   Thus, method 1 - requiring support for this extension - is the
preferred
> approach and the only means for this extension to be practically useful to
> applications. Method 2 - requiring the use of crit -
> while theoretically useful to ensure that confusion between encoded and
> unencoded payloads cannot occur, is not particularly useful in practice,
since
> method 1 is still required for the extension to be usable. When method 1
is
> employed, method 2 doesn't add any value and since it increases the size
of the
> JWS, its use is not required by this specification."
> >
> >> Nits/editorial comments:
> >>
> >> In the security considerations, the last sentence of the first
> >> paragraph needs to be simplified. I suggest replacing it with:
> >>
> >> "It then becomes the responsibility of the application to ensure that
> >> payloads only contain characters that will not cause parsing problems
> >> for the serialization used, as described in Section 5. The
> >> application also incurs the responsibility to ensure that the payload
> >> will not be modified during retransmission.
> > I have simplified this in the manner that you suggested.
> >
> > Thanks again,
> > -- Mike
> 
> ___
> jose mailing list
> j...@ietf.org
> https://www.ietf.org/mailman/listinfo/jose

___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

[Gen-art] Gen-ART Review of draft-ietf-mpls-rfc6374-udp-return-path-04

[Wassim Haddad]

I am the assigned Gen-ART reviewer for this draft. For background on Gen-ART, 
please see the FAQ at >

Document: draft-ietf-mpls-rfc6374-udp-return-path-04
Reviewer:  Wassim Haddad
Review Date: 14 December 2015
IETF LC End Date: 15 December 2015
IETF Telechat Date: unknown

Summary:  This draft is ready for publication as proposed RFC

- Major Issues: None

- Minor Issues: None


Regards,

Wassim H.



___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

[Gen-art] Gen-ART Review of draft-ietf-mpls-rfc6374-udp-return-path-04

[Wassim Haddad]

Re-sending…



> Begin forwarded message:
> 
> From: Wassim Haddad 
> Date: December 14, 2015 at 11:07:05 PST
> To: 
> Cc: Wassim Haddad , 
> 
> Subject: [Gen-art] Gen-ART Review of 
> draft-ietf-mpls-rfc6374-udp-return-path-04
> 
> I am the assigned Gen-ART reviewer for this draft. For background on Gen-ART, 
> please see the FAQ at 
>  >
> 
> Document: draft-ietf-mpls-rfc6374-udp-return-path-04
> Reviewer:  Wassim Haddad
> Review Date: 14 December 2015
> IETF LC End Date: 15 December 2015
> IETF Telechat Date: unknown
> 
> Summary:  This draft is ready for publication as proposed RFC
> 
> - Major Issues: None
> 
> - Minor Issues: None
> 
> 
> Regards,
> 
> Wassim H.

___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

[Gen-art] Genart Telechat review draft-ietf-eppext-keyrelay-11

[Robert Sparks]

I am the assigned Gen-ART reviewer for this draft. The General Area
Review Team (Gen-ART) reviews all IETF documents being processed
by the IESG for the IETF Chair. Please wait for direction from your
document shepherd or AD before posting a new version of the draft.

For more information, please see the FAQ at

.

Document: draft-ietf-eppext-keyrelay-11
Reviewer: Robert Sparks
Review Date: 14Dec2015
IETF LC End Date: 4Dec2015
IESG Telechat date: 17Dec2015

Summary: (Still) ready for publication as Proposed Standard

Thanks for addressing most of my nits.

I think it's a problem (not for this document, but for the overall work) 
that draft-koch-dnsop-operator-change isn't moving forward. I think the 
group should spend energy on how to capture what it was saying.


I also still think you would have a stronger document if it discussed 
the SHOULD NOT in the security section as I suggest below. I think you 
read that to be me suggesting you change it to MUST NOT. That was not 
the intent. I was asking you to add to the document _why_ it wasn't MUST 
NOT.


On 11/25/15 3:45 PM, Robert Sparks wrote:

I am the assigned Gen-ART reviewer for this draft. The General Area
Review Team (Gen-ART) reviews all IETF documents being processed
by the IESG for the IETF Chair.  Please treat these comments just
like any other last call comments.

For more information, please see the FAQ at

.

Document: draft-ietf-eppext-keyrelay-10
Reviewer: Robert Sparks
Review Date: 25Nov2015
IETF LC End Date: 4Dec2015
IESG Telechat date: (not yet scheduled)

Summary: Ready for publication as Proposed Standard with nits

This is a small nit, but please consider changing the document to 
address it. The motivation for this extension leans on improving the 
security of transferring information between registrars. It should be 
recast as providing better automation and reliability instead. In 
practice (and I think in specification), it hinges on passing a 
password from the registrar of record to the gaining registrar through 
some unspecified means (though typically through the registrant). That 
password is required to be placed in the create by the gaining 
registrar as specified in this document in order for that create to 
succeed at the registry. While it would be impractical and 
error-prone, the same channel that was used to hand this password 
around _could_ be used to pass the keying material this extension 
addresses.


Reading draft-koch-dnsop-operator-change (an informational reference 
currently) helped greatly with understanding this document. That draft 
expired in 2014. Please be sure it advances, and consider making it a 
normative reference.
If it is not going to move forward, consider pulling some of the 
transfer mechanic recommendations and the definitions of 
losing/gaining entities into this draft, unless they've already made 
it into the RFC series somewhere else?


The security considerations document says a server SHOULD NOT perform 
any transformation on data under server management when processing a 
 command. Can this point to more detailed discussion 
somewhere? Why is this not a MUST NOT? (What are the conditions where 
violating the SHOULD NOT is the right thing to do? What are the risks 
a server takes if it performs such a transformation?)


Micro-nit : In section 2.1 where you say "The  element MUST 
contain one of the following", consider saying "The  element 
MUST contain exactly one of the following".


RjS




___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

Re: [Gen-art] Gen-ART Review of draft-ietf-dnsop-edns-client-subnet-04

[Warren Kumari]

>
> NOTES TO AUTHORS: I went to try integrate these changes and discovered
that the most recently published version of the document is -04, but the
version in github  (
https://github.com/wkumari/draft-vandergaast-edns-client-subnet ) is
version -06.
I have rolled this back to -05 and published as that. There are 2 places
below when I need some help with text.

On Fri, Dec 11, 2015 at 6:26 PM Russ Housley  wrote:

> I am the assigned Gen-ART reviewer for this draft. The General Area
>
> Review Team (Gen-ART) reviews all IETF documents being processed
>
> by the IESG for the IETF Chair. Please wait for direction from your
>
> document shepherd or AD before posting a new version of the draft.
>
>
> For more information, please see the FAQ at
>
> .
>
>
> Document: draft-ietf-dnsop-edns-client-subnet-04
>
> Reviewer: Russ Housley
>
> Review Date: 2015-12-11
>
> IETF LC End Date: 2015-12-21
>
> IESG Telechat date: unknown
>
>
> Summary:  Almost Ready
>
>
>
>
Thank you for taking the time to review this document.


> Major Concerns:
>
>
> In Section 6, the figure includes a line that begins with "7:".  This
>
> is incorrect.  It should begin with "8:".
>
>
Doh! Thanks.



> Section 7.2.1 ends with: "Implementations SHOULD document their chosen
>
> behavior."  I have no objection to such documentation, but some advice
>
> about where someone might find it would be useful.  I do not think you
>
> are asking each implementation to write an Informational RFC.  Further,
>
> the use of "SHOULD" in this sentence has nothing to do with the normal
> RFC 2119 usage, which applies to the action taken by an implementation.
>

Good point. I've updated this to be:
"This choice should be documented for the operator, for example in the user
manual. "
Does this work for you?



> Section 7.5 says:
>
>
>Intermediate Nameservers supporting ECS MUST forward options with
>
>SOURCE PREFIX-LENGTH set to 0 (that is, completely anonymized).  Such
>
>options MUST NOT be replaced with more accurate address information.
>
>
>An Intermediate Nameserver MAY also forward ECS options with actual
>
>address information.  This information MAY match the source IP
>
>address of the incoming query, and MAY have more or fewer address
>
>bits than the Nameserver would normally include in a locally
>
>originated ECS option.
>
>
> These two paragraphs appear to contradict each other.  I cannot figure
>
> out what an Intermediate Nameservers that supports forwarding of ECS
> options ought to do with regard to source address information.
>

Yup, that was confusing. How is: "An Intermediate Nameserver MAY forward
ECS options with address information. This information MAY match the source
IP address of the incoming query, and MAY have more or fewer address bits
than the Nameserver would normally include in a locally originated ECS
option. If an Intermediate Nameservers receives a query with SOURCE
PREFIX-LENGTH set to 0 it MUST forward the query as-is and MUST NOT replace
it with more accurate address information." ?


>
> Please divide the references into normative and informative.  The URIs
>
> should be informative references.  URIs must be stable references, and
> I do not think that [4] qualifies.
>

Thank you.
These have been fixed.
[4] Has now been published as an ID, and so is now stable(r) -
 I-D.hardie-privsec-metadata-insertion


>
>
> Minor Concerns:
>
>
> The last paragraph of the Introduction provides information that is
>
> useful to someone doing a review.  However, it is not clear to me that
>
> this information belongs in the Informational RFC.  I think that it
>
> would be sufficient to say:
>
>
>At least a dozen different client and server implementations have been
>
>written based on earlier versions of this specification.  The protocol
>
>is in active production use today.  While the implementations
>
>interoperate, there is varying behaviour around edge cases that were
>
>poorly specified.  Known incompatibilities are described in this
>
>document, and the authors believe that it is better to describe the
>
>system as it is working today, even if not everyone agrees with the
>
>details of the original specification [1].  The alternative is an
>
>undocumented and proprietary system.
>
>
Thank you.
The current text was arrived at after many iterations - I *think* that your
text will still keep everyone happy and so have incorporated it.


If you accept this approach, then you might also look for "original
> draft" elsewhere in the document ans make a compatible change.
>

Thank you.


>
> In Section 6, I think it would be useful to say that the SCOPE
>
> PREFIX-LENGTH in a response MUST be less than or equal to the SOURCE
>
> PREFIX-LENGTH.
>
>
> In Section 7.1.1, can you add a sentence or reference to explain "lame
>
> delegation"?  I recognize that this type of error results when a name
>

Re: [Gen-art] Resolution on comments of draft-ietf-l2vpn-vpls-pe-etree-10

[Ben Campbell]

Hi,

This (I assume still unsubmitted) version addresses my IESG ballot 
comments.


Thanks!

Ben.

On 11 Dec 2015, at 5:16, Jiangyuanlong wrote:


Hi all,

Thanks a lot for your reviews.
Based on all the comments received during the IESG evaluation, we have 
prepared a tentative version 11 for this draft.
We believe all the comments are resolved, but please check whether you 
have any concerns with the texts in this version.


If there are no further comments, we will upload it as the formal 
revision 11 version.


Best regards,
Yuanlong


-Original Message-
From: BRUNGARD, DEBORAH A [mailto:db3...@att.com]
Sent: Thursday, December 03, 2015 11:03 PM
To: Jari Arkko
Cc: Jiangyuanlong; Russ Housley; 
draft-ietf-l2vpn-vpls-pe-etree@ietf.org; IETF

Gen-ART; IETF
Subject: Re: [Gen-art] Gen-ART Review of 
draft-ietf-l2vpn-vpls-pe-etree-10


Hi Jari,

Yes, we'll be doing a new revision for addressing other comments.

I've asked for today's telechat if no discusses to mark it as 
approved, revised

draft needed.

Much thanks Russ for your review!

Deborah


Sent from my iPhone


On Dec 3, 2015, at 1:08 PM, Jari Arkko  wrote:

Many thanks for your detailed review, Russ!

Yuanlong, will there be a new draft version or other edits before 
the draft

is approved?

Jari


On 17 Nov 2015, at 00:53, Jiangyuanlong 

wrote:


Russ,

Thanks a lot for your review and good observations.
Please see my comments in line.

Best regards,
Yuanlong


-Original Message-
From: Russ Housley [mailto:hous...@vigilsec.com]
Sent: Saturday, November 14, 2015 1:28 AM
To: draft-ietf-l2vpn-vpls-pe-etree@ietf.org
Cc: IETF Gen-ART; IETF
Subject: Gen-ART Review of draft-ietf-l2vpn-vpls-pe-etree-10

I am the assigned Gen-ART reviewer for this draft. The General 
Area Review
Team (Gen-ART) reviews all IETF documents being processed by the 
IESG for
the IETF Chair. Please wait for direction from your document 
shepherd or AD

before posting a new version of the draft.

For more information, please see the FAQ at
.

Document: draft-ietf-l2vpn-vpls-pe-etree-10
Reviewer: Russ Housley
Review Date: 2015-11-13
IETF LC End Date: 2015-11-24
IESG Telechat date: unknown

Summary:  Almost Ready


Major Concerns: None


Minor Concerns:

Sections 4.1 and 5.3.1 inclues a reference to [802.1Q-2011].  
Should this be
the 2014 version of the document?  If not, please add the 
informative

reference for [802.1Q-2011].

[YJ] Yes, all these should refer to [802.1Q-2014].



Other Editorial Comments:

The Abstract should appear on the title page.

[YJ] OK.


Section 3 needs a reference for MEF 6.1:
s/Specification MEF 6.1/Specification MEF 6.1 [MEF6.1]/ Also, 
[MEF6.1]

needs to be added as a normative reference.

[YJ] All these will be updated to MEF 6.2.


Section 3 needs a reference for IEEE 802.1Q-2003:
s/B.1.3 of IEEE 802.1Q-2003/B.1.3 of IEEE 802.1Q-2003 
[802.1Q-2003]/ Also,

please add an informative reference for [802.1Q-2003].

[YJ] Yes, we will add an informative reference for [802.1Q-2003].

Third level section headings do not have space between the section 
number

and the section title.  For example:
s/5.3.1.PW Processing/5.3.1. PW Processing/

[YJ] OK.

In Fig 4, there is room to shift the figure to the right, this 
will allow the "AC"

labels to fit better on the left:

 ++
 |   VPLS-capable PE model|
 |   +---+  +--+  |
 |   |   |==|TVSI-1|
+---+  AC  |   |     | PWs
|CE |--| Bridge  |
+---+  |   |   | Root &   +--+  |
 |   | Module| Leaf VLAN   o  |
 |   |   | o  |
 |   |   | o  |
 |   |   | o  |
 |   |   | o  |
+---+  AC  |   |   |   VLAN-n +--+  |
|CE |--|   VSI-n |-
+---+  |   |   |==|  |- 
PWs

 |   |   | ^|  |-
 |   +---+ |+--+  |
 | |  |
 +-|--+
   LAN emulation Interface

 Figure 4  A VPLS PE Model for E-Tree with a Single T-VSI



[YJ] OK.

___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art




___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art