Re: [Gen-art] Review of draft-ietf-nvo3-use-case-15

[Lucy yong]

Hi Ralph,

Thank you for the review. We will have all acronyms expansion in next version 
and add a reference for DC services.  

Regards,
Lucy

-Original Message-
From: Gen-art [mailto:gen-art-boun...@ietf.org] On Behalf Of Ralph Droms
Sent: Friday, January 06, 2017 7:14 AM
To: gen-art@ietf.org
Cc: n...@ietf.org; draft-ietf-nvo3-use-case@ietf.org; i...@ietf.org
Subject: [Gen-art] Review of draft-ietf-nvo3-use-case-15

Reviewer: Ralph Droms
Review result: Ready with Nits

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-nvo3-use-case-??
Reviewer: Ralph Droms
Review Date: 2017-01-06
IETF LC End Date: 2017-01-11
IESG Telechat date: 2017-01-19

Summary: This draft is ready for publication as an Informational RFC.

Major issues: None

Minor issues: None

Nits/editorial comments: 

I found several acronyms that did not have expansions.  I recommend a pass over 
the document for unexpanded acronyms..

Section 2: What is "broadcast/unknown" traffic (spec. "unknown"?); please 
expand the acronym "BUM".
  The paragraph that begins with "One NVO3 network [...]" is indented 
differently from the rest of the text.  Intentional or a typo?

Section 3.2: An illustrating figure for the use case described in this section 
would be helpful.
  Expand acronyms "PE" and "ABSR".
  I found the text using "Option A" and "Option B" confusing.  Exactly what are 
those options?

Section 5: I didn't understand the references to IaaS, PaaS and SaaS in the 
summary - there are no references to those services in the body of the 
document, or back pointers from the summary to relevant preceding text.

___
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

[Gen-art] Review of draft-harkins-owe-05

[Lucy Yong]

Reviewer: Lucy Yong
Review result: Ready with Nits

The draft is nearly ready for the publication.
 
Minor comment: Suggest adding this in security considerations: OWE
provides encryption over the wireless medium, i.e., Wi-Fi without
authentication. Thus it does not provide security for end-to-end
traffic.  users should still use application level security such as
VPN for end-to-end security. In this case, use of OWE prevents VPN
authentication info. to be spoofed in open public Wi-Fi.
one question: Will a user notices if OWE is used or not?  This may be
important for some users. 

nit: r/encryption of the wireless medium/encryption over the wireless
medium/



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

Re: [Gen-art] Review: draft-ietf-pim-join-attributes-for-lisp-05

[Lucy yong]

Thank you, Dino. Good, I understand it now.

Lucy

-Original Message-
From: Dino Farinacci [mailto:farina...@gmail.com] 
Sent: Thursday, December 01, 2016 1:53 PM
To: Lucy yong
Cc: Jari Arkko; draft-ietf-pim-join-attributes-for-l...@tools.ietf.org; General 
Area Review Team; Stig Venaas
Subject: Re: [Gen-art] Review: draft-ietf-pim-join-attributes-for-lisp-05

> OK, forget my suggestion. I have a difficulty to parse this sentence 
> (second part)
> 
>  It determines the downstream destination for unicast head-end 
> replication and identifies the  receiver ETR that needs to be notified 
> should the root of the  distribution tree move to another site.
> 
> Lucy

First off, let’s include the entire paragraph:

   Knowledge of the receiver ETR's RLOC address is also essential to the
   control plane of the root ITR.  It determines the downstream
   destination for unicast head-end replication and identifies the
   receiver ETR that needs to be notified should the root of the
   distribution tree move to another site.

How about we change to this:

   Knowledge of the receiver ETR's RLOC address is also essential to the
   control plane of the root ITR.  The RLOC address determines the downstream
   destination for unicast head-end replication and identifies the
   receiver ETR that needs to be notified should the root ITR of the
   distribution tree move to another site. The root ITR can change when the
   source EID is roaming to another LISP site.

Dino

> 
> -Original Message-
> From: Dino Farinacci [mailto:farina...@gmail.com]
> Sent: Thursday, December 01, 2016 1:45 PM
> To: Lucy yong
> Cc: Jari Arkko; 
> draft-ietf-pim-join-attributes-for-l...@tools.ietf.org; General Area 
> Review Team; Stig Venaas
> Subject: Re: [Gen-art] Review: 
> draft-ietf-pim-join-attributes-for-lisp-05
> 
> 
>> Could you make this sentence more readable?
>> 
>>  It determines the downstream destination for unicast head-end 
>> replication and identifies the  receiver ETR that needs to be 
>> notified should the root of the  distribution tree move to another site.
>> 
>> "should be", "moving”?
> 
> I do not understand what you are suggesting. Write more words please.
> 
> Dino
> 
> 

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

Re: [Gen-art] Review: draft-ietf-pim-join-attributes-for-lisp-05

[Lucy yong]

OK, forget my suggestion. I have a difficulty to parse this sentence (second 
part)

  It determines the downstream destination for unicast head-end replication and 
identifies the
  receiver ETR that needs to be notified should the root of the
  distribution tree move to another site.

Lucy

-Original Message-
From: Dino Farinacci [mailto:farina...@gmail.com] 
Sent: Thursday, December 01, 2016 1:45 PM
To: Lucy yong
Cc: Jari Arkko; draft-ietf-pim-join-attributes-for-l...@tools.ietf.org; General 
Area Review Team; Stig Venaas
Subject: Re: [Gen-art] Review: draft-ietf-pim-join-attributes-for-lisp-05


> Could you make this sentence more readable?
> 
>   It determines the downstream destination for unicast head-end replication 
> and identifies the
>   receiver ETR that needs to be notified should the root of the
>   distribution tree move to another site.
> 
> "should be", "moving”?

I do not understand what you are suggesting. Write more words please.

Dino


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

Re: [Gen-art] Review: draft-ietf-pim-join-attributes-for-lisp-05

[Lucy yong]

Hi Dino,

Sorry, I did not have time to study RFC6831 for this review work and may not 
interpret the draft properly by reading it. I trust you on the protocol design 
and have no objection on Jari's decision.

Could you make this sentence more readable?

   It determines the downstream destination for unicast head-end replication 
and identifies the
   receiver ETR that needs to be notified should the root of the
   distribution tree move to another site.

"should be", "moving"?

Thanks,
Lucy
-Original Message-
From: Dino Farinacci [mailto:farina...@gmail.com] 
Sent: Thursday, December 01, 2016 1:07 PM
To: Jari Arkko
Cc: Lucy yong; draft-ietf-pim-join-attributes-for-l...@tools.ietf.org; General 
Area Review Team; Stig Venaas
Subject: Re: [Gen-art] Review: draft-ietf-pim-join-attributes-for-lisp-05

> Lucy,
> 
> Many thanks for your review.
> 
> Dino, Stig, does this discussion lead you to consider adding some 
> clarifications to the document? I am not going to require those (just posted 
> a no-obj for the document on today’s telechat), but wanted to give you an 
> opportunity to consider that.
> 
> Jari

The base LISP multicast architecture is all explained in RFC6831. From the type 
of commentary from Lucy’s email, it led me to believe she (1) had not read 
RFC6831 or (2) did not understand the content of RFC6831.

Discussing how LISP multicast works in a PIM document is a misplacement of 
information and risks contradicting what is in the LISP published RFCs.

Dino

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

[Gen-art] Review: draft-ietf-manet-credit-window-07

[Lucy yong]

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



<http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.



Document: draft-ietf-manet-credit-window-07

 Credit Windowing extension for DLEP

Reviewer: Lucy Yong

Review Date: 28-Nov-2016

IETF LC End Date: 28-Nov-2016

IESG Telechat date: 29-Nov-2016



Summary: This document specifies a technique for a fine-grained flow control in 
radio communication. It is well-written and ready for publishing. Note: 07 
version is published recently and is reviewed.



Major issues: N/A



Minor issues: N/A



Nits/editorial comments:

In section 9.1, revise "If credits are to used on a destination, ...", to make 
it readable.



Regards,

Lucy



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

Re: [Gen-art] Review: draft-ietf-pim-join-attributes-for-lisp-05

[Lucy yong]

 Dino,

please see inline below.


>> the draft assumes that PIM works within individual LISP sites but PIM 
>> mcast transport may not be supported among LISP sites. However the 
>> mechanism itself does not enforce a unique (unicast or mcast) 
>> underlay transport among LISP sites. Could some ETRs request unicast 
>> transport, other request multicast transport? The mechanism requires 
>> all LISP xTRs to run PIM protocol, right?
> 
> We are sending a PIM join and we assume that the upstream LIS xTR is 
> supporting PIM. This is similar to RFC 6831. If PIM is not supported, the 
> join message would be ignored. As we mention in section 4 we want to allow a 
> mixture of multicast and unicast forwarding.
> [Lucy] I am thinking that how many PIM protocol instance may run in 
> this case, one is within a LISP

Two. One at all LISP sites (not one per LISP site) and part of the overlay and 
possibly one in the underlay.
[Lucy] Thank, Dino. This is helpful. So the attributes proposed in this draft 
is used in the first PIM instance, right? These attributes are only used by 
ETRs to send join/prune msg to ITR (root).

> site, one is for LISP underlay network, and one among LISP xTRs, is 
> this right? PIM protocol instance running for LISP xTRs is a special 
> version with additional LISP related attributes? When configuring

I don’t know what you mean by “additional LISP related attributes”. The LISP 
xTR runs PIM and sends unicast PIM Join/Prune messages to other xTRs.
[Lucy] I mean the attribute is per LISP specific implementation.

> PIM protocol on a device, do we need to differ them in configuration? Sorry 
> to ask these, I have not yet read RFC6831 but understand what you want to 
> achieve here.

That is implementation specific.
[Lucy] PIM is a protocol running on top of IGP. Now we have PIM LISP 
implementation specific. Within a LISP site, PIM has no change; the LISP 
implementation are only on XTRs.
 And the details are in RFC6831. And if you are going to do a quality review of 
this document, you should read RFC 6831.
[Lucy] I hear you. 

>> PIM join/prune msg are designed for PIM protocol. These two 
>> attributes are specifically designed for LISP purpose. Any concern 
>> here? From PIM perspective, they are optional attributes; are they 
>> "MUST" attributes for LISP (mcast)?
> 
> It is possible to do multicast according to 6831 without these 
> attributes. As we mention in this

Yes, if multicast is in the underlay and reaches every LISP site. But the point 
is, it may not. Plus this draft can be used when RFC 6831 is NOT used but when 
draft-ietf-lisp-signal-free-multicast is used so the ITR can know if multicast 
RLOCs can be used. 

But the best test to know if a multicast RLOC should be used is to RLOC-probe 
it and see all the ETRs that reply. Then you know which ETRs can received the 
encapsulated multicast packet via a multicast underlay. And the ones that 
don’t, you unicast replicate. This is the case where multicast partially 
deployed in the underlay.
[Lucy] You are the expert on this subject. From the draft text, I am not able 
to picture these. 

Regards,
Lucy

Dino

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

Re: [Gen-art] Review: draft-ietf-pim-join-attributes-for-lisp-05

[Lucy yong]

Hi Stig and Dino,

Pls see inline below.

-Original Message-
From: Stig Venaas (svenaas) [mailto:s...@cisco.com] 
Sent: Tuesday, October 18, 2016 3:39 PM
To: Lucy yong; draft-ietf-pim-join-attributes-for-l...@tools.ietf.org; A. Jean 
Mahoney; General Area Review Team
Subject: Re: [Gen-art] Review: draft-ietf-pim-join-attributes-for-lisp-05

Hi

Thanks for the review Lucy, please see comments inline.

On 10/17/2016 12:09 PM, Lucy yong wrote:
> //
>
>
>
> Send again.  fix some template info.
>
> / /
>
> *From:*Lucy yong
> *Sent:* Monday, October 17, 2016 1:59 PM
> *To:* A. Jean Mahoney; General Area Review Team; 
> 'draft-ietf-pim-join-attributes-for-lisp@tool.ietf.org'
> *Subject:* [Gen-art] Review: 
> draft-ietf-pim-join-attributes-for-lisp-05
>
>
>
> 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
>
>
>
> <http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.
>
>
>
> Document: draft-ietf-pim-join-attributes-for-lisp-05
>
>  PIM Join Attributes for LISP environments.
>
> Reviewer: Lucy Yong
>
> Review Date: 17-Oct-2016
>
> IETF LC End Date: 24-Oct-2016
>
> IESG Telechat date:
>
>
>
> Summary: This document specifies two new PIM join/prune attributes for 
> facilitating PIM mcast transports across LISP sites.*//*Some issues 
> need to be considered prior to publishing.
>
>
>
> Major issues:
>
>
>
> the draft assumes that PIM works within individual LISP sites but PIM 
> mcast transport may not be supported among LISP sites. However the 
> mechanism itself does not enforce a unique (unicast or mcast) underlay 
> transport among LISP sites. Could some ETRs request unicast transport, 
> other request multicast transport? The mechanism requires all LISP 
> xTRs to run PIM protocol, right?

We are sending a PIM join and we assume that the upstream LIS xTR is supporting 
PIM. This is similar to RFC 6831. If PIM is not supported, the join message 
would be ignored. As we mention in section 4 we want to allow a mixture of 
multicast and unicast forwarding.
[Lucy] I am thinking that how many PIM protocol instance may run in this case, 
one is within a LISP site, one is for LISP underlay network, and one among LISP 
xTRs, is this right? PIM protocol instance running for LISP xTRs is a special 
version with additional LISP related attributes? When configuring PIM protocol 
on a device, do we need to differ them in configuration? Sorry to ask these, I 
have not yet read RFC6831 but understand what you want to achieve here.
>
>
> PIM join/prune msg are designed for PIM protocol. These two attributes 
> are specifically designed for LISP purpose. Any concern here? From PIM 
> perspective, they are optional attributes; are they "MUST" attributes 
> for LISP (mcast)?

It is possible to do multicast according to 6831 without these attributes. As 
we mention in this draft, the transport attribute is useful in telling the 
upstream whether to use unicast or multicast.
6831 only talks about multicast.
[Lucy] This means that without using this attribute, it means use of multicast 
transport. Good to make that clear in the document for backward compatibility. 
Alternative is only using this attribute when unicast transport is requested.

We also discuss in this section 5 how the ETR RLOC attribute is helpful in 
determining the unicast destination address and for root-EID mobility. As we 
mention, one could without the RLOC attribute instead use the outer source 
address of the LISP encapsulated J/P message, but that may not necessarily be 
the best/right address to use. So I think we are explaining how one can do LISP 
multicast without these new attributes, but there are benefits in using them. 
So in short, they are not "MUST" attributes, but there are good reasons for 
using them.
[Lucy] So this attribute is only benefit for unicast case.

> Minor issues: the draft uses many PIM and LISP terms without any 
> explanation. It is hard for a reader to read it without knowledge of 
> PIM and LISP protocol and terms.

We could perhaps clarify some, but I think we should expect someone reading 
this in order to implement it, or in order to understand an implementation, to 
have some knowledge of both PIM and LISP. At least terms like RLOC, EID, ITR, 
ETR and xTR.

> It is not clear if Receiver RLOC attribute only applies to unicast 
> transport or both unicast/mcast transport. Need to clarify.

Perhaps we should make this clearer. Currently we have this text in section 5:

To support root-EID mobility, receiver ETRs must

[Gen-art] Review: draft-ietf-pim-join-attributes-for-lisp-05

[Lucy yong]

Send again.  fix some template info.

From: Lucy yong
Sent: Monday, October 17, 2016 1:59 PM
To: A. Jean Mahoney; General Area Review Team; 
'draft-ietf-pim-join-attributes-for-lisp@tool.ietf.org'
Subject: [Gen-art] Review: draft-ietf-pim-join-attributes-for-lisp-05


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



<http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.



Document: draft-ietf-pim-join-attributes-for-lisp-05

 PIM Join Attributes for LISP environments.

Reviewer: Lucy Yong

Review Date: 17-Oct-2016

IETF LC End Date: 24-Oct-2016

IESG Telechat date:



Summary: This document specifies two new PIM join/prune attributes for 
facilitating PIM mcast transports across LISP sites. Some issues need to be 
considered prior to publishing.



Major issues:



the draft assumes that PIM works within individual LISP sites but PIM mcast 
transport may not be supported among LISP sites. However the mechanism itself 
does not enforce a unique (unicast or mcast) underlay transport among LISP 
sites. Could some ETRs request unicast transport, other request multicast 
transport? The mechanism requires all LISP xTRs to run PIM protocol, right?



PIM join/prune msg are designed for PIM protocol. These two attributes are 
specifically designed for LISP purpose. Any concern here? From PIM perspective, 
they are optional attributes; are they "MUST" attributes for LISP (mcast)?





Minor issues: the draft uses many PIM and LISP terms without any explanation. 
It is hard for a reader to read it without knowledge of PIM and LISP protocol 
and terms.



It is not clear if Receiver RLOC attribute only applies to unicast transport or 
both unicast/mcast transport. Need to clarify.



Backward compatibility, without these two attributes in a join/prune msg from a 
LISP ETR, what that mean?



Nits/editorial comments:


Section 1: "to be notified should the root of the
   distribution tree move to another site."  Should "should" be "that"?

Section 5: several 'must' should be "MUST"

Regards,
Lucy


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

[Gen-art] FW: Review: draft-ietf-pim-join-attributes-for-lisp-05

[Lucy yong]

Send again.

From: Lucy yong
Sent: Monday, October 17, 2016 1:59 PM
To: A. Jean Mahoney; General Area Review Team; 
'draft-ietf-pim-join-attributes-for-lisp@tool.ietf.org'
Subject: [Gen-art] Review: draft-ietf-pim-join-attributes-for-lisp-05


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



<http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.



Document: draft-ietf-tictoc-multi-path-synchronization-05

 Multi-Path Time Synchronization

Reviewer: Joel Halpern

Review Date: 15-Sept-2016

IETF LC End Date: 28-Sept-2016

IESG Telechat date: 29-Sept-2016



Summary: This document specifies two new PIM join/prune attributes for 
facilitating PIM mcast transports across LISP sites.



Major issues:



the draft assumes that PIM works within individual LISP sites but PIM mcast 
transport may not be supported among LISP sites. However the mechanism itself 
does not enforce a unique (unicast or mcast) underlay transport among LISP 
sites. Could some ETRs request unicast transport, other request multicast 
transport? The mechanism requires all LISP xTRs to run PIM protocol, right?



PIM join/prune msg are designed for PIM protocol. These two attributes are 
specifically designed for LISP purpose. Any concern here? From PIM perspective, 
they are optional attributes; are they "MUST" attributes for LISP (mcast)?





Minor issues: the draft uses many PIM and LISP terms without any explanation. 
It is hard for a reader to read it without knowledge of PIM and LISP protocol 
and terms.



It is not clear if Receiver RLOC attribute only applies to unicast transport or 
both unicast/mcast transport. Need to clarify.



Backward compatibility, without these two attributes in a join/prune msg from a 
LISP ETR, what that mean?



Nits/editorial comments:


Section 1: "to be notified should the root of the
   distribution tree move to another site."  Should "should" be "that"?

Section 5: several 'must' should be "MUST"

Regards,
Lucy


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

[Gen-art] Review: draft-ietf-pim-join-attributes-for-lisp-05

[Lucy yong]

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-tictoc-multi-path-synchronization-05

 Multi-Path Time Synchronization

Reviewer: Joel Halpern

Review Date: 15-Sept-2016

IETF LC End Date: 28-Sept-2016

IESG Telechat date: 29-Sept-2016



Summary: This document specifies two new PIM join/prune attributes for 
facilitating PIM mcast transports across LISP sites.



Major issues:



the draft assumes that PIM works within individual LISP sites but PIM mcast 
transport may not be supported among LISP sites. However the mechanism itself 
does not enforce a unique (unicast or mcast) underlay transport among LISP 
sites. Could some ETRs request unicast transport, other request multicast 
transport? The mechanism requires all LISP xTRs to run PIM protocol, right?



PIM join/prune msg are designed for PIM protocol. These two attributes are 
specifically designed for LISP purpose. Any concern here? From PIM perspective, 
they are optional attributes; are they "MUST" attributes for LISP (mcast)?





Minor issues: the draft uses many PIM and LISP terms without any explanation. 
It is hard for a reader to read it without knowledge of PIM and LISP protocol 
and terms.



It is not clear if Receiver RLOC attribute only applies to unicast transport or 
both unicast/mcast transport. Need to clarify.



Backward compatibility, without these two attributes in a join/prune msg from a 
LISP ETR, what that mean?



Nits/editorial comments:


Section 1: "to be notified should the root of the
   distribution tree move to another site."  Should "should" be "that"?

Section 5: several 'must' should be "MUST"

Regards,
Lucy


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

[Gen-art] Review: draft-ietf-ipsecme-ddos-protection-09

[Lucy yong]

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



<http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.



Document: draft-ietf-ipsecme-ddos-protection-09

 Multi-Path Time Synchronization

Reviewer: Lucy Yong

Review Date: 23-Sept-2016

IETF LC End Date: 28-Sept-2016

IESG Telechat date: 29-Sept-2016



Summary: This document is nearly ready for publication as a standard track RFC. 
Some minor comments. Some nits need to be corrected.



PS: comment for IESG. The document specifies puzzles approach and related 
protocol to boost the difficulty for DDoS attacks. The protocol description is 
simple and short; however it spends many pages (section 7) to describe the 
processes at the Initiator and the Responder. Maybe in future IETF can consider 
accepting protocol software code in a RFC. This will be easier for author and 
no need for programmers to read the description and program it (sure they will 
not come out the same program logic).



Major issues: N/A



Minor issues:



Section 1: 2nd paragraph, bot-nets,

Comment: what is the bot-nets?



Section 7.1.1.2, 1st paragraph

Comment: "that must be used", should it be "that MUST be used" or "that is 
used"?





Nits/editorial comments:



Section 6:



s/the puzzle difficulty should/the puzzle difficulty SHOULD/



s/This will This will/This will/


Section 7.1

s/the IKE Responder should/the IKE Responder SHOULD/
s/that puzzles/puzzles/

Section 7.1.1.1
s/next to/nearly/
s/the level should/the level SHOULD/

Section 7.1.1.2
s/([RFC7696])/[RFC7696]/
s/with another, and negotiate/with another and negotiate/
s/an SA payload, containing/an SA payload containing/
s/this type must/this type MUST/

Section 7.1.1.3
s/should/SHOULD/ (3 places)
s/blob/block/
s/may continue to generate/MAY continually generate/

Section 7.1.3
s/the solution to the puzzle contain/the puzzle solution contains/
s/i.e./i.e.,/ (2 places)

Section 7.1.4
s/must/MUST/ (2 places)

Section 7.2
s/The Responder should/The Responder SHOULD/

Section 7.2.2
s/message, containing/message containing/

Section 7.2.4
s/operations i.e.  computing/operations, i.e., computing/

Section 8.1
s/PRF must/PRF MUST/

Section 9
s/Initiators should/Initiators SHOULD/

Section 10
s/Care must/Care MUST/








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

[Gen-art] [Gem-art] Gem-ART review of draft-moriaty-pkcs1-03

[Lucy yong]

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>
Document:   draft-moriaty-pkcs1-03
Reviewer:     Lucy Yong
Review Date:   15 September 2016
IETF LC End Date:2 September 2016

Summary:
The document is well written, and is ready for publication as Informational 
RFC. IPR considerations are in Appendix D.
Major Issues:None
Minor Issues:

* Several places use xxx-PKCS-v1_5, should it be xxx-PKCS1-v1_5? where 
xxx may be EMSA, RSAES, and RSASSA.
Editorial Issues:

* Please check the Idnits tool

* Page 18: s/k - 2hLen -2/k - 2hLen - 2/

* Page 18: s/"knowing"the/"knowing" the/

* Page 40: s/ -- such as the salt value in EMSA-PSS --/ such as the 
salt value in EMSA-PSS/

* replace Section 7.2.2. title with "Decryption operation"

* In Section 8.2, s/Note:/Note./   (to be consistent with the rest of 
doc.)

* Section 8.2 last paragraph, replace "recommended" with "RECOMMENDED"
Regards,
Lucy
___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

Re: [Gen-art] Generate review of draft-ietf-tsvwg-gre-in-udp-encap-16

[Lucy yong]

Hi Jouni,

David and I work on it to address your comments.

Thanks,
Lucy 

-Original Message-
From: Jouni Korhonen [mailto:jouni.nos...@gmail.com] 
Sent: Thursday, August 18, 2016 10:40 AM
To: Lucy yong; gen-art@ietf.org (gen-art@ietf.org); 
draft-ietf-tsvwg-gre-in-udp-encap@ietf.org
Subject: Re: [Gen-art] Generate review of draft-ietf-tsvwg-gre-in-udp-encap-16

Hi Lucy,

See inline ;)

8/12/2016, 2:10 PM, Lucy yong kirjoitti:
> Hi Jouni,
>
> OOPS, forget this one, sorry.
>
> o My “complaint” of this document is basically on the following.. these are 
> writing
>style things so feel free to neglect:
>- It repeats.. the same statements multiple times.
> Lucy: perhaps some can reference previous section.

See my response to Davin on this. Basically, when you say "this document 
specifies.." etc do not spread that to multiple paragraphs and sections. 
Keep them in one place and not in increamental style spread around.

>- When reading the document I get the feeling it is actually two 
> documents. The
>  technical specification (which is very short) and the general deployment
>  considerations document. I would have split it to two but that is just 
> me.
> Lucy: When we were developing this document, we kindly became clear 
> ourselves, we need to address two parts and want to do in one document.

There's definitely wordsmithing to do here. Now the "guidelines" and protocol 
specification (the very short one) and kind of mixed, which to me makes reading 
a bit confusing experience. If you want to keep all in one document, it is fine 
by me. I was just expressing my personal opinion on structuring.

- JOuni

>
> Regards,
> Lucy
>
>
>
> -Original Message-
> From: Gen-art [mailto:gen-art-boun...@ietf.org] On Behalf Of Jouni
> Sent: Friday, August 12, 2016 1:51 AM
> To: gen-art@ietf.org (gen-art@ietf.org); 
> draft-ietf-tsvwg-gre-in-udp-encap@ietf.org
> Subject: [Gen-art] Generate review of 
> draft-ietf-tsvwg-gre-in-udp-encap-16
>
> 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
>
> <http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.
>
> Document: draft-ietf-tsvwg-gre-in-udp-encap-16
> Reviewer: Jouni Korhonen
> Review Date: 8/11/2016
> IETF LC End Date: 2016-08-12
> IESG Telechat date: (if known)
>
> Summary:  Ready with minor nits.
>
> Major issues: None.
>
> Minor issues: Read on..
>
> Editorials/nits:
>  o My “complaint” of this document is basically on the following.. these are 
> writing
>style things so feel free to neglect:
>- It repeats.. the same statements multiple times.
>- When reading the document I get the feeling it is actually two 
> documents. The
>  technical specification (which is very short) and the general deployment
>  considerations document. I would have split it to two but that is just 
> me.
>
> The other nits.
>
>  o There are bunch of acronyms that are not expanded either never or on their 
> first use.
>Some examples include UDP, DSCP, DS, PMTU, MPLS, VNP, .. Pay attention to 
> these.
>  o In the Introduction give a reference to EtherType e.g., the repository 
> where they
>are maintained or by whom they are maintained.
>  o On line 129 is says:
>  This document specifies GRE-in-UDP tunnel requirements for two
>Based on the earlier text I would suggest saying “..document also 
> specifies..”
>  o On line 143 I would also (following the previous style in the paragraph) 
> capitalize
>“wide area networks” as well.
>  o In multiple places (lines 236, 887) the reference is after the full stop. 
> Place full
>stop after the reference.
>  o The document uses both tunnel ingress/egress and 
> encapsulator/decapsulator. Is there a
>specific reason to have this differentiation? If not use common 
> terminology throughout
>the document.
>  o On line 654 is says:
>   MUST comply with requirement 1 and 8-10 in Section 5 of
>How is this “MUST” enforced?
>  o In Section 7.1 I find it a bit odd discussing NATs in the specific context 
> of IPv6. If
>you have a specific IPv6 NAT scenario in mind either spell it out or give 
> a reference
>to a specification that describes the technology/use case.
>  o In Section 8 and lines 784-785 has a “MUST NOT” for traffic that is not 
> known to be
>congestion-controlled.. I would be interested in knowing how to enforce 
> this “MUST”
>specifically in the Internet case.
>  o Line 909 typo “ether” -> “either”.
>
> ___
> 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

Re: [Gen-art] Generate review of draft-ietf-tsvwg-gre-in-udp-encap-16

[Lucy yong]

Hi Jouni,

OOPS, forget this one, sorry.

o My “complaint” of this document is basically on the following.. these are 
writing
   style things so feel free to neglect:
   - It repeats.. the same statements multiple times.
Lucy: perhaps some can reference previous section. 
   - When reading the document I get the feeling it is actually two documents. 
The
 technical specification (which is very short) and the general deployment
 considerations document. I would have split it to two but that is just me.
Lucy: When we were developing this document, we kindly became clear ourselves, 
we need to address two parts and want to do in one document.

Regards,
Lucy



-Original Message-
From: Gen-art [mailto:gen-art-boun...@ietf.org] On Behalf Of Jouni
Sent: Friday, August 12, 2016 1:51 AM
To: gen-art@ietf.org (gen-art@ietf.org); 
draft-ietf-tsvwg-gre-in-udp-encap@ietf.org
Subject: [Gen-art] Generate review of draft-ietf-tsvwg-gre-in-udp-encap-16

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-tsvwg-gre-in-udp-encap-16
Reviewer: Jouni Korhonen
Review Date: 8/11/2016
IETF LC End Date: 2016-08-12
IESG Telechat date: (if known)

Summary:  Ready with minor nits.

Major issues: None.

Minor issues: Read on..

Editorials/nits:
 o My “complaint” of this document is basically on the following.. these are 
writing
   style things so feel free to neglect:
   - It repeats.. the same statements multiple times.
   - When reading the document I get the feeling it is actually two documents. 
The
 technical specification (which is very short) and the general deployment
 considerations document. I would have split it to two but that is just me.

The other nits.

 o There are bunch of acronyms that are not expanded either never or on their 
first use. 
   Some examples include UDP, DSCP, DS, PMTU, MPLS, VNP, .. Pay attention to 
these.
 o In the Introduction give a reference to EtherType e.g., the repository where 
they
   are maintained or by whom they are maintained.
 o On line 129 is says: 
   This document specifies GRE-in-UDP tunnel requirements for two
   Based on the earlier text I would suggest saying “..document also 
specifies..”
 o On line 143 I would also (following the previous style in the paragraph) 
capitalize
   “wide area networks” as well.
 o In multiple places (lines 236, 887) the reference is after the full stop. 
Place full
   stop after the reference.
 o The document uses both tunnel ingress/egress and encapsulator/decapsulator. 
Is there a
   specific reason to have this differentiation? If not use common terminology 
throughout
   the document.
 o On line 654 is says:
MUST comply with requirement 1 and 8-10 in Section 5 of
   How is this “MUST” enforced?
 o In Section 7.1 I find it a bit odd discussing NATs in the specific context 
of IPv6. If
   you have a specific IPv6 NAT scenario in mind either spell it out or give a 
reference
   to a specification that describes the technology/use case.
 o In Section 8 and lines 784-785 has a “MUST NOT” for traffic that is not 
known to be
   congestion-controlled.. I would be interested in knowing how to enforce this 
“MUST”
   specifically in the Internet case.
 o Line 909 typo “ether” -> “either”.

___
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

Re: [Gen-art] Generate review of draft-ietf-tsvwg-gre-in-udp-encap-16

[Lucy yong]

Hi Jouni,

Thank you for the review and correction. Pls see inline below.

-Original Message-
From: Gen-art [mailto:gen-art-boun...@ietf.org] On Behalf Of Jouni
Sent: Friday, August 12, 2016 1:51 AM
To: gen-art@ietf.org (gen-art@ietf.org); 
draft-ietf-tsvwg-gre-in-udp-encap@ietf.org
Subject: [Gen-art] Generate review of draft-ietf-tsvwg-gre-in-udp-encap-16

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-tsvwg-gre-in-udp-encap-16
Reviewer: Jouni Korhonen
Review Date: 8/11/2016
IETF LC End Date: 2016-08-12
IESG Telechat date: (if known)

Summary:  Ready with minor nits.

Major issues: None.

Minor issues: Read on..

Editorials/nits:
 o My “complaint” of this document is basically on the following.. these are 
writing
   style things so feel free to neglect:
   - It repeats.. the same statements multiple times.
   - When reading the document I get the feeling it is actually two documents. 
The
 technical specification (which is very short) and the general deployment
 considerations document. I would have split it to two but that is just me.

The other nits.

 o There are bunch of acronyms that are not expanded either never or on their 
first use. 
   Some examples include UDP, DSCP, DS, PMTU, MPLS, VNP, .. Pay attention to 
these.
[Lucy] I will check. 
 o In the Introduction give a reference to EtherType e.g., the repository where 
they
   are maintained or by whom they are maintained.
[Lucy] I will put RFC7042 as the reference.
 o On line 129 is says: 
   This document specifies GRE-in-UDP tunnel requirements for two
   Based on the earlier text I would suggest saying “..document also 
specifies..”
[Lucy] ack.
 o On line 143 I would also (following the previous style in the paragraph) 
capitalize
   “wide area networks” as well.
[Lucy] ack.
 o In multiple places (lines 236, 887) the reference is after the full stop. 
Place full
   stop after the reference.
[Lucy] My mistake. Will correct them.
 o The document uses both tunnel ingress/egress and encapsulator/decapsulator. 
Is there a
   specific reason to have this differentiation? If not use common terminology 
throughout
   the document.
[Lucy] I would prefer to use two teams in the document. Tunnel ingress and 
egress is the view from network perspective,
And encapsulator/decapsulator is the view at the ingress or egress. E.g. it is 
odd to say encapsulator IP address. I open to add a clarification if that 
causes a concern.

 o On line 654 is says:
MUST comply with requirement 1 and 8-10 in Section 5 of
   How is this “MUST” enforced?
[Lucy] Do you concern on the wording or the implementation? 

 o In Section 7.1 I find it a bit odd discussing NATs in the specific context 
of IPv6. If
   you have a specific IPv6 NAT scenario in mind either spell it out or give a 
reference
   to a specification that describes the technology/use case.
[Lucy] This section describes middlebox specialty on IPv6 traffic. Most UDP 
applications do not perform UDP checksum in IPv4 network; most UDP applications 
perform UDP checksum in IPv6 network because of IPv6 requirement [RFC2460]. 
Thus some middleboxes validate UDP checksum if it is in IPv6. [RFC6935] 
[RFC6936] relax the need to perform UDP checksum in some special cases, which 
is applicable to this draft. But we need to state out the potential impact that 
is specific in IPv6.  
 o In Section 8 and lines 784-785 has a “MUST NOT” for traffic that is not 
known to be
   congestion-controlled.. I would be interested in knowing how to enforce this 
“MUST”
   specifically in the Internet case.
[Lucy] By IETF standard. :)  How about replace "MUST NOT" with "are not 
appropriate"? (match the wording in requirement 3 of Section 2.1.1)  
 o Line 909 typo “ether” -> “either”.
[Lucy] ack. Thx. 

Regards,
Lucy

___
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

Re: [Gen-art] Gen-ART Last Call Review of draft-ietf-l2vpn-etree-frwk-06

[Lucy yong]

Hi Jari,

I have fixed the nits identified by Ben and upload the new version (08).

Thanks,
Lucy 

-Original Message-
From: Jari Arkko [mailto:jari.ar...@piuha.net] 
Sent: Wednesday, August 06, 2014 6:00 PM
To: Lucy yong
Cc: Ben Campbell; gen-art@ietf.org Team (gen-art@ietf.org); i...@ietf.org list; 
draft-ietf-l2vpn-etree-frwk@tools.ietf.org
Subject: Re: [Gen-art] Gen-ART Last Call Review of 
draft-ietf-l2vpn-etree-frwk-06

Thanks for the review, Ben. Looks like the substantive issues have been 
resolved and the editorial ones are on their way to be fixed. (Thanks Lucy!)

Jari

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

Re: [Gen-art] Gen-ART Last Call Review of draft-ietf-l2vpn-etree-frwk-06

[Lucy yong]

Hi Ben,

See my reply inline w/ [lucy]

I apologize for the late response. I somehow missed your mail when it came in 
originally. Comments inline. I've deleted sections where I don't have further 
comment.
[Lucy] No problem.

Thanks!

Ben.

On Jul 15, 2014, at 3:18 PM, Lucy yong lucy.y...@huawei.com wrote:
 

[...]

 -- I suggest removing the 2119 language. Ignoring the general controversies 
 over whether informational RFCs should use 2119 language, I don't think it 
 fits for _this_ draft. In particular, all the small number of normative 
 language instances seems to be either statements of fact or restatements of 
 requirements that are defined elsewhere. These would all be better served 
 with descriptive language. 
 [Lucy] OK. I will change as you suggested.
 

The 2119 language has been removed, but you still have a reference to RFC 2119 
in the reference section.
[Lucy] Sorry. Forget to remove that. We can fix that.

[...]

 
 5.2 seems like the same gap as discussed in 5.1, just from a perspective of 
 CA role vs forwarding constraint. Handing around constraints vs roles seem 
 more like solution questions than requirements or architecture questions.
 [Lucy] One is assigned the role at AC that impacts the forwarding; another is 
 to convey or advertise the assigned AC role. Since these may relate to 
 different techniques used in L2VPN, it is good to keep them in different 
 sections. 
 

Okay
[Lucy] good.

[...]

 Nits/editorial comments:
 
 -- 2.2, 4th paragraph: Furthermore, MEF also defines AC roles. One
   role is Root and another is Leaf.
 
 Are these the same usages as defined in this document? If so, it might be 
 helpful to attribute these in the terminology section.
 [Lucy] We define Root AC and Leaf AC in terminology and use them in the 
 framework. Will that be OK?
 

My comment was that _this_ document defines the roles, but also says that MEF 
defines them. If those definitions are the same, then it would useful for the 
definitions in this draft to mention that the usage is the same as defined by 
MEF, or say in section 2.2. that MEF defines these terms the same way as this 
draft.
[Lucy] Agree. We can clarify that the AC role definition in this doc is the 
same as the OVC EP role definition in MEF. (OVC EP: Operator virtual connection 
end point).

Thanks,
Lucy

[...]

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

Re: [Gen-art] Gen-ART Last Call Review of draft-ietf-l2vpn-etree-frwk-06

[Lucy yong]

Hi Ben,

Thank you for the review and suggestions. Please see inline below w/ [Lucy]

-Original Message-
From: Ben Campbell [mailto:b...@nostrum.com] 
Sent: Monday, July 14, 2014 5:40 PM
To: draft-ietf-l2vpn-etree-frwk@tools.ietf.org
Cc: gen-art@ietf.org Team (gen-art@ietf.org); i...@ietf.org list
Subject: Gen-ART Last Call Review of draft-ietf-l2vpn-etree-frwk-06

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-l2vpn-etree-frwk-06
Reviewer: Ben Campbell
Review Date: 2014-07-14
IETF LC End Date: 2014-07-15

Summary: This draft is almost ready for publication as an RFC, but I have a few 
minor issues and editorial comments that may be worth consideration prior to 
publication.

Major issues:

None

Minor issues:

-- I suggest removing the 2119 language. Ignoring the general controversies 
over whether informational RFCs should use 2119 language, I don't think it fits 
for _this_ draft. In particular, all the small number of normative language 
instances seems to be either statements of fact or restatements of requirements 
that are defined elsewhere. These would all be better served with descriptive 
language. 
[Lucy] OK. I will change as you suggested.

-- Section 4, paragraph after Table 1: If direct Layer 2 Leaf-to-Leaf 
communication needs to be prohibited, E-Tree should be used.

That sounds more like advocacy than architecture/framework. Do you mean to 
suggest that other potential solutions (if any) should not be used, or that 
E-Tree is somehow the best solution?  Or did you mean to say E-Trees are 
appropriate for whenever...?
[Lucy] OK, I will change the wording.

-- Similarly, 2 paragraphs down: An E-Tree service can meet these use case 
requirements.

That also sounds like advocacy. This draft doesn't seem to do a requirements 
analysis for those use cases, beyond an assumption that they need inter-leaf 
isolation at Layer 2. Something to the effect of E-Trees can meet the common 
requirement to avoid the exchange of frames between Leaf CAs. would be more 
appropriate.
[Lucy] OK. Will fix that.

-- 5.1 and 5.2:

5.2 seems like the same gap as discussed in 5.1, just from a perspective of 
CA role vs forwarding constraint. Handing around constraints vs roles seem more 
like solution questions than requirements or architecture questions.
[Lucy] One is assigned the role at AC that impacts the forwarding; another is 
to convey or advertise the assigned AC role. Since these may relate to 
different techniques used in L2VPN, it is good to keep them in different 
sections. 

-- 5.3, First sentence:

The first sentence seems like yet a further restatement of the issue from 5.1 
and 5.2.  (The rest of the section seems reasonably distinct from the others.)
[Lucy] Yeah. I will remove the first sentence.

-- Security Considerations:

The security considerations mostly say that e-trees have to act like e-trees. I 
think there is room for more discussion. Are the e-tree rules sufficient for 
scenarios where inter-leaf isolation is critical for security reasons? Does it 
remove needs for higher layer protections? (I hope not.) The guidance to use 
IPSec if additional security is required is not entirely satisfying here--how 
would an higher layer protocol know whether or not it had a fully protected 
path?
[Lucy] For the first point, yes, E-tree can be used to inter-leaf isolation for 
the security reason. However higher layer does not have any knowledge of AC 
role at lower layer, I don't think that it can rely on the lower layer for the 
protection.  I'll add that clarification. For the second point, to clarify, 
E-Tree is an L2 service that is implemented over MPLS network, not IP 
underlying. If an operator chooses running the mpls over IP network, such 
security concern need to be addressed there. This has no change on the security 
that the mpls provides.

Are there trust issues between PEs? Can one PE assume that another will enforce 
the leave/root constraints? Can it trust that the other PE has the same idea of 
what should be a leaf vs root? Is there a need for one PE to determine if 
another supports E-Trees at all?
[Lucy] A MPLS domain is operated by an operator. Thus, there is trust between 
PEs. I will explicitly make that clear in this section.


Nits/editorial comments:

-- 2.2, 4th paragraph: Furthermore, MEF also defines AC roles. One
   role is Root and another is Leaf.

Are these the same usages as defined in this document? If so, it might be 
helpful to attribute these in the terminology section.
[Lucy] We define Root AC and Leaf AC in terminology and use them in the 
framework. Will that be OK?

-- 2.3, 2nd paragraph: ... distinct differentiation for multicast groups in 
one VPN.

I suggest ... distinct differentiation among multicast groups in the same