Re: [Gen-art] Gen-art LC review: draft-ietf-taps-transports-11

[Jari Arkko]

Thanks for the review, Robert.

Jari



signature.asc
Description: Message signed with OpenPGP using GPGMail
___
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-siprec-callflows-07

[Jari Arkko]

Thank you very much for your review, Dan. Authors, have you taken a look at 
Dan’s comments?

Jari

On 25 Nov 2016, at 14:16, Dan Romascanu  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-siprec-callflows-07
> 
> Reviewer: Dan Romascanu
> Review Date: 11/25/16
> IETF LC End Date: 11/27/16
> IESG Telechat date: (if known) 12/2/16
> 
> Summary: Ready.
> 
> This is a very useful supporting document in the SIPREC cluster.
> 
> Major issues:
> 
> None
> 
> Minor issues:
> 
> None
> 
> 
> Nits/editorial comments:
> 
> 1. The title is slightly misleading, as the document does not have as goal to 
> document all or the most important call flows, but rather to provide a 
> grouping of significant examples. 'Examples of SUP Recording Call Flows' may 
> have been a better title.
> 
> 2. As the document uses terminology defined in [RFC7865] and [RFC6341], 
> listing these two RFCs as Normative References seems necessary (can't 
> understand the terms without reading the two RFCs)
> 
> 3. typo in the Securoty Considerations section: '
> 
> Security considerations mentioned in [RFC7865] and [RFC7866] has to be 
> followed ...
> 
> s/has to/have to/
> 
> ___
> Gen-art mailing list
> Gen-art@ietf.org
> https://www.ietf.org/mailman/listinfo/gen-art



signature.asc
Description: Message signed with OpenPGP using GPGMail
___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

Re: [Gen-art] Review: draft-bbf-bbf-urn-02

[Jari Arkko]

Thanks for the review & the edits.

jari

On 24 Nov 2016, at 02:24, Joel Halpern  wrote:

> The new version addresses my concerns and is ready for publication as an 
> informational RFC.
> 
> Yours,
> Joel M. Halpern
> 
> On 10/14/16 4:51 PM, Joel M. Halpern 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-bbf-bbf-urn-02
>>Uniform Resource Name (URN) Namespaces for Broadband Forum
>> Reviewer: Joel M. Halpern
>> Review Date: 14-October-2016
>> IETF LC End Date: 4-November-2016
>> IESG Telechat date: N/A
>> 
>> Summary: This document is almost ready for publication as an
>> Informational RFC.
>> 
>> Major issues:
>>RFC 3406 states that the namespace considerations section should
>> indicate why a new namespace is needed.  While this is pretty obvious,
>> the text does not actually say anything in that section to explain it.
>>In particular, I would expect that section to explain why 3 NIDs are
>> needed rather than just 1.
>> 
>> 
>> Minor issues:
>>The template in RFC 3406 indicates the the section in each NID on
>> the Process of identifier assignment should "detail the mechanism and or
>> authorities for assigning URNs to resources."  The draft simply says
>> that the BBF will provide procedures.  Do those procedures exist?  If
>> not, there seems to be a minor problem.  If they do exist, it would seem
>> sensible to include a pointer to the place where the BBF publicly
>> documents those procedures, so that people using this information who
>> might want to register something can understand what the rules and
>> expectations are. (I realize that the RFC 6289 example this is based on
>> did not include such a pointer, which is why I am making this a minor
>> comment instead of a major one.)
>> 
>> Nits/editorial comments:
>> 
>> ___
>> 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



signature.asc
Description: Message signed with OpenPGP using GPGMail
___
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-siprec-callflows-07

[Ram Mohan R (rmohanr)]

Hi Jari,

Yes. I just replied to Dan’s comment. Will take care of all of them. Thanks for 
your review.

Regards,
Ram

-Original Message-
From: Jari Arkko 
Date: Thursday, 1 December 2016 at 7:08 PM
To: Dan Romascanu 
Cc: , 
Subject: Re: [Gen-art] Gen-ART review of draft-ietf-siprec-callflows-07
Resent-From: , 
Resent-To: , , 
, , , 
, , , Andrew 
Hutton , 
Resent-Date: Thu, 1 Dec 2016 05:38:11 -0800

Thank you very much for your review, Dan. Authors, have you taken a look at 
Dan’s comments?

Jari

On 25 Nov 2016, at 14:16, Dan Romascanu  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-siprec-callflows-07
> 
> Reviewer: Dan Romascanu
> Review Date: 11/25/16
> IETF LC End Date: 11/27/16
> IESG Telechat date: (if known) 12/2/16
> 
> Summary: Ready.
> 
> This is a very useful supporting document in the SIPREC cluster.
> 
> Major issues:
> 
> None
> 
> Minor issues:
> 
> None
> 
> 
> Nits/editorial comments:
> 
> 1. The title is slightly misleading, as the document does not have as 
goal to document all or the most important call flows, but rather to provide a 
grouping of significant examples. 'Examples of SUP Recording Call Flows' may 
have been a better title.
> 
> 2. As the document uses terminology defined in [RFC7865] and [RFC6341], 
listing these two RFCs as Normative References seems necessary (can't 
understand the terms without reading the two RFCs)
> 
> 3. typo in the Securoty Considerations section: '
> 
> Security considerations mentioned in [RFC7865] and [RFC7866] has to be 
followed ...
> 
> s/has to/have to/
> 
> ___
> 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-6lo-privacy-considerations-04

[Jari Arkko]

Paul: thank you for the review!

Jari

On 28 Nov 2016, at 20:09, Paul Kyzivat  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 
> <​http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.
> 
> Document: draft-ietf-6lo-privacy-considerations-04
> Reviewer: Paul Kyzivat
> Review Date: 2016-11-28
> IETF LC End Date: 2016-11-30
> IESG Telechat date: 2016-12-01
> 
> Summary:
> 
> This draft is ready for publication as an Informational RFC.
> 
> Issues: IdNits reports a couple of outdated references that should be 
> updated, but this will be done as a matter of course.
> 
> ___
> Gen-art mailing list
> Gen-art@ietf.org
> https://www.ietf.org/mailman/listinfo/gen-art



signature.asc
Description: Message signed with OpenPGP using GPGMail
___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

Re: [Gen-art] Gen-ART telechat review of draft-ietf-tsvwg-diffserv-intercon-12

[Jari Arkko]

Thanks for the review and fixes!

Jari



signature.asc
Description: Message signed with OpenPGP using GPGMail
___
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-siprec-callflows-07

[Dan Romascanu]

Hi Ran,

Thanks for addressing all my concerns and congratulations to you and your
colleagues for the good work.

Regards,

Dan




On Thu, Dec 1, 2016 at 3:53 PM, Ram Mohan R (rmohanr) 
wrote:

> Hi Dan,
>
> Thanks for your review. Please see inline
>
> From: Dan Romascanu 
> Date: Friday, 25 November 2016 at 5:46 PM
> To: "gen-art@ietf.org" , "draft-ietf-siprec-callflows.
> a...@tools.ietf.org" 
> Subject: Gen-ART review of draft-ietf-siprec-callflows-07
> Resent-From: , 
> Resent-To: , , <
> pkyzi...@alum.mit.edu>, , , <
> b...@nostrum.com>, , , Andrew
> Hutton ,  a...@ietf.org>
> Resent-Date: Friday, 25 November 2016 at 5:46 PM
>
> 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-siprec-callflows-07
>
> Reviewer: Dan Romascanu
> Review Date: 11/25/16
> IETF LC End Date: 11/27/16
> IESG Telechat date: (if known) 12/2/16
>
> Summary: Ready.
>
> This is a very useful supporting document in the SIPREC cluster.
>
> Major issues:
>
> None
>
> Minor issues:
>
> None
>
>
> Nits/editorial comments:
>
> 1. The title is slightly misleading, as the document does not have as goal
> to document all or the most important call flows, but rather to provide a
> grouping of significant examples. 'Examples of SUP Recording Call Flows'
> may have been a better title.
>
>  I agree. The document contains only most important call flows. So I
> will rename to “Examples of SIP Recording Call Flows”
>
> 2. As the document uses terminology defined in [RFC7865] and [RFC6341],
> listing these two RFCs as Normative References seems necessary (can't
> understand the terms without reading the two RFCs)
>
>  agree. Will do that.
>
> 3. typo in the Securoty Considerations section: '
>
> Security considerations mentioned in [RFC7865] and [RFC7866] has to be
> followed ...
>
> s/has to/have to/
>
>  Thanks will fix it.
>
> Regards
> Ram
>
>
>
>
___
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-siprec-callflows-07

[Ram Mohan R (rmohanr)]

Hi Dan,

Thanks for your review. Please see inline

From: Dan Romascanu 
Date: Friday, 25 November 2016 at 5:46 PM
To: "gen-art@ietf.org" , 
"draft-ietf-siprec-callflows@tools.ietf.org" 

Subject: Gen-ART review of draft-ietf-siprec-callflows-07
Resent-From: , 
Resent-To: , , 
, , , 
, , , Andrew 
Hutton , 
Resent-Date: Friday, 25 November 2016 at 5:46 PM

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-siprec-callflows-07

Reviewer: Dan Romascanu
Review Date: 11/25/16
IETF LC End Date: 11/27/16
IESG Telechat date: (if known) 12/2/16

Summary: Ready.

This is a very useful supporting document in the SIPREC cluster.

Major issues:

None

Minor issues:

None


Nits/editorial comments:

1. The title is slightly misleading, as the document does not have as goal to 
document all or the most important call flows, but rather to provide a grouping 
of significant examples. 'Examples of SUP Recording Call Flows' may have been a 
better title.

 I agree. The document contains only most important call flows. So I will 
rename to “Examples of SIP Recording Call Flows”

2. As the document uses terminology defined in [RFC7865] and [RFC6341], listing 
these two RFCs as Normative References seems necessary (can't understand the 
terms without reading the two RFCs)

 agree. Will do that.

3. typo in the Securoty Considerations section: '

Security considerations mentioned in [RFC7865] and [RFC7866] has to be followed 
...

s/has to/have to/

 Thanks will fix it.

Regards
Ram



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

[Gen-art] Review of draft-ieee-urn-03

[IETF Secretariat]

Reviewer: Pete Resnick
Review result: Ready

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-ieee-urn-03
Reviewer: Pete Resnick
Review Date: 2016-12-01
IETF LC End Date: 2016-11-14
IESG Telechat date: 2016-12-01

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

Just a simple registration document. No concerns.

Major issues:

None

Minor issues:

None

Nits/editorial comments:

None

___
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

[Jari Arkko]

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



signature.asc
Description: Message signed with OpenPGP using GPGMail
___
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-kitten-pkinit-freshness-07

[Michiko Short]

Ok, since answer not obvious starting thread on Kitten. 

-Original Message-
From: Jari Arkko [mailto:jari.ar...@piuha.net] 
Sent: Thursday, December 1, 2016 1:30 AM
To: Benjamin Kaduk 
Cc: Paul Miller (NT) ; Michiko Short 
; IETF Gen-ART ; 
draft-ietf-kitten-pkinit-freshness@ietf.org
Subject: Re: [Gen-art] Gen-ART Review of draft-ietf-kitten-pkinit-freshness-07

Many thanks for your review, Russ, and for thinking about this space and what 
issues there might be.

I too am concerned about the issue that Russ Housley raised: bad practices in 
creating the freshness tokens creates a security issue. If this cannot be 
handled in the way that Russ initially suggested (setting a minimum number of 
bits) then a proper discussion of the issue and recommendations to avoid the 
problems need to be included in the security considerations section.

I fully recognise the point from the authors that different styles of creating 
the tokens result in different implications, and that setting a mere minimum 
number of bits may not be appropriate.

Jari

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

[Gen-art] QRE: Gen-ART Review of draft-ietf-kitten-pkinit-freshness-07

[Michiko Short]

One thing to note, since the client will never know what the KDC is using size 
will not impact the error or AS-REQ processing unless we can declare a 
universal min and max. It can be used by the KDC since it will know if nonce, 
sym crypto or asym crypto. So the example that Russ provided was client 
behavior which would not be impacted. However, the KDCs can use this 
information to fail the Freshness token validation before cracking open the 
token.

-Original Message-
From: Michiko Short [mailto:michi...@microsoft.com] 
Sent: Thursday, December 1, 2016 9:33 AM
To: Jari Arkko ; Benjamin Kaduk 
Cc: Paul Miller (NT) ; IETF Gen-ART ; 
draft-ietf-kitten-pkinit-freshness@ietf.org
Subject: RE: [Gen-art] Gen-ART Review of draft-ietf-kitten-pkinit-freshness-07

Ok, since answer not obvious starting thread on Kitten. 

-Original Message-
From: Jari Arkko [mailto:jari.ar...@piuha.net] 
Sent: Thursday, December 1, 2016 1:30 AM
To: Benjamin Kaduk 
Cc: Paul Miller (NT) ; Michiko Short 
; IETF Gen-ART ; 
draft-ietf-kitten-pkinit-freshness@ietf.org
Subject: Re: [Gen-art] Gen-ART Review of draft-ietf-kitten-pkinit-freshness-07

Many thanks for your review, Russ, and for thinking about this space and what 
issues there might be.

I too am concerned about the issue that Russ Housley raised: bad practices in 
creating the freshness tokens creates a security issue. If this cannot be 
handled in the way that Russ initially suggested (setting a minimum number of 
bits) then a proper discussion of the issue and recommendations to avoid the 
problems need to be included in the security considerations section.

I fully recognise the point from the authors that different styles of creating 
the tokens result in different implications, and that setting a mere minimum 
number of bits may not be appropriate.

Jari

___
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

[Dino Farinacci]

> 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

[Jari Arkko]

That would work for me.

Jari



signature.asc
Description: Message signed with OpenPGP using GPGMail
___
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

[Dino Farinacci]

> 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

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]

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

[Dino Farinacci]

> 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

[Dino Farinacci]

There is no other text in the email. So can’t be sure what you are saying. I’m 
guessing you are fine with the proposed text?

My co-authors have to agree though.  ;-)

Dino

> On Dec 1, 2016, at 11:55 AM, Jari Arkko  wrote:
> 
> That would work for me.
> 
> Jari
> 

___
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

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

[Jari Arkko]

On 01 Dec 2016, at 22:01, Dino Farinacci  wrote:

> There is no other text in the email. So can’t be sure what you are saying. 
> I’m guessing you are fine with the proposed text?

yes, the one that you proposed



signature.asc
Description: Message signed with OpenPGP using GPGMail
___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

[Gen-art] A *new* batch of IETF LC reviews - 2016-12-01

[A. Jean Mahoney]

Hi all,

NOTE: This email contains links to the new review tool
  functionality in Datatracker.

  The old review tool (art.tools.ietf.org/tools/art/genart/)
  is now deprecated, use Datatracker instead.


The following reviewers have assignments:

Reviewer  LC end  Draft
-

Francis Dupont2016-12-13  draft-ietf-core-http-mapping-17 *

Jouni Korhonen2016-12-26  draft-elie-nntp-tls-recommendations-01

Paul Kyzivat  2016-12-13  draft-ietf-oauth-amr-values-04

* 2nd LC

Reviewers should have seen emails from Datatracker informing them of the 
assignments. If you did not receive an email, please let me know.


I have made the assignments in Datatracker:
https://datatracker.ietf.org/group/genart/reviews/

To access your individual review page, log into to Datatracker:
https://datatracker.ietf.org/accounts/review/

Assignments are also captured in the spreadsheets (for now):
http://wiki.tools.ietf.org/dav/genart/gen-art.html
http://wiki.tools.ietf.org/dav/genart/gen-art-by-reviewer.html

The template is included below (There's an enhancement ticket to include 
it in Datatracker: https://trac.tools.ietf.org/tools/ietfdb/ticket/2075).


Thanks!

Jean

---

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:
Reviewer:
Review Date:
IETF LC End Date:
IESG Telechat date: (if known)

Summary:

Major issues:

Minor issues:

Nits/editorial comments:

___
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-straw-b2bua-rtcp-15

[Jari Arkko]

Many thanks for your excellent review, Russ.

I plan to watch the resolution of the Discusses related to the unclear SHOULD 
NOT. (It certainly would have been a Discuss from me if a Discuss wasn’t 
already raised.)

At this point I do not plan to block on the document class, but looking forward 
to further discussion if people want to argue it.

Jari



signature.asc
Description: Message signed with OpenPGP using GPGMail
___
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-kitten-pkinit-freshness-07

[Jari Arkko]

Many thanks for your review, Russ, and for thinking about this space and what 
issues there might be.

I too am concerned about the issue that Russ Housley raised: bad practices in 
creating the freshness tokens creates a security issue. If this cannot be 
handled in the way that Russ initially suggested (setting a minimum number of 
bits) then a proper discussion of the issue and recommendations to avoid the 
problems need to be included in the security considerations section.

I fully recognise the point from the authors that different styles of creating 
the tokens result in different implications, and that setting a mere minimum 
number of bits may not be appropriate.

Jari



signature.asc
Description: Message signed with OpenPGP using GPGMail
___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

Re: [Gen-art] Gen-ART Telechat review of draft-ietf-behave-ipfix-nat-logging-11

[Jari Arkko]

Thanks much for your review, Paul!

Do the authors have any comments? Paul’s review comments should be addressed. I 
think that at least the Section 5.6 question is something that you must address.

Jari

On 28 Nov 2016, at 19:06, Paul Kyzivat  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 <​http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.
> 
> Document: draft-ietf-behave-ipfix-nat-logging-11
> Reviewer: Paul Kyzivat
> Review Date:
> IETF LC End Date: 2016-02-12
> IESG Telechat date: 2016-12-01
> 
> Summary:
> 
> This draft is on the right track but has open issues, described in the review.
> 
> Major: 0
> Minor: 5
> Nits:  1
> 
> (1) Minor:
> 
> A sentence in Section 3 says: "This document focuses exclusively on the 
> specification of IPFIX IEs." But this statement appears to be false. A large 
> part of the document (Section 5.6) specifies Templates. It appears to be an 
> important aspect of the document that goes beyond specifying just IEs. So the 
> statement should be expanded.
> 
> (2) Minor:
> 
> Section 5.2 starts with "The templates could contain a subset of the 
> Information Elements(IEs) shown in Table 1 depending upon the event being 
> logged."
> 
> This is not a normative statement. It isn't clear what is normative regarding 
> the use and content of templates. If I understand RFC7011, a NAT device can 
> use any number of templates, and those templates can reference any defined 
> IE. Is *this* document intended to *restrict* the form and number of 
> templates used for logging NAT devices? Or is it simply suggesting some 
> templates that may be modified as desired to fit the needs of a particular 
> NAT device device?
> 
> These templates do not have any Information Element that uniquely identifies 
> to the IPFIX collector that this template is being used. So how does the 
> collector know that the particular event is intended to follow the 
> definitions in this draft, rather than simply some proprietary template? 
> Absent that, how do normative statements of what must be in the template mean 
> anything?
> 
> (3) Minor:
> 
> Section 5.6 says: "Depending on the implementation and configuration various 
> IEs specified can be included or ignored."
> 
> What is the normative intent of this statement? Is it defining what is meant 
> by the "Mandatory" field in the tables? (I.e., that in the templates it sends 
> the NAT device MUST include fields with Mandatory=Yes but MAY omit fields 
> with Mandatory=No.) This should be revised to make the normative behavior 
> clearer.
> 
> (4) Minor:
> 
> Within the IANA Considerations, section 8.1 deals with Information Elements, 
> with one subsection for each new IE being defined. Some of these (8.1.4 
> natQuotaExceededEvent, 8.1.5 netThresholdEvent, 8.1.6 netEvent) each require 
> a new IANA subregistry to be defined. They do this rather informally within 
> the body of the corresponding subsection. Perhaps IANA will figure this out, 
> but there is opportunity for misunderstanding. It would be better if there 
> were separate subsection of section 8 for each of these registry creation 
> actions. E.g. 8.2 NAT Quota Exceeded Event Type, 8.3 NAT Threshhold Event 
> Type, 8.4 NAT Event Type.
> 
> (5) Minor:
> 
> Section 9 appears to be normative, since it uses 2119 language. But it 
> appears at a position in the document (after Acknowledgements and IANA 
> Considerations, before Security Considerations), where I would normally not 
> expect to find normative language.
> 
> Perhaps this is intended to be more of an appendix. If so, then the normative 
> language should be removed, and it ought to be formatted as an appendix.
> 
> If it is intended to be normative, then I suggest that it be moved ahead of 
> the Acknowledgements.
> 
> (6) Nit:
> 
> Running IDNits returns a number of issues, mostly regarding references.
> 
> ___
> Gen-art mailing list
> Gen-art@ietf.org
> https://www.ietf.org/mailman/listinfo/gen-art



signature.asc
Description: Message signed with OpenPGP using GPGMail
___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

Re: [Gen-art] Review: draft-ietf-dnsop-resolver-priming-09

[Jari Arkko]

Thanks for your review, Joel!

Jari

On 31 Oct 2016, at 00:47, Joel M. Halpern  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-dnsop-resolver-priming-09
>Initializing a DNS Resolver with Priming Queries
> Reviewer: Joel M. Halpern
> Review Date: 30-October-2016
> IETF LC End Date: 10-November-2016
> IESG Telechat date: (if known)
> 
> Summary: This document is ready for publication as a BCP.
> 
> Major issues:
> 
> Minor issues:
> 
> Nits/editorial comments:
> 
> ___
> Gen-art mailing list
> Gen-art@ietf.org
> https://www.ietf.org/mailman/listinfo/gen-art



signature.asc
Description: Message signed with OpenPGP using GPGMail
___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

Re: [Gen-art] Gen-art Telechat review: draft-ietf-kitten-rfc6112bis-03

[Jari Arkko]

Thanks for your review, Robert, and thanks everyone for addressing the earlier 
comments.

Jari



signature.asc
Description: Message signed with OpenPGP using GPGMail
___
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-leiba-3967upd-downref-00

[Jari Arkko]

Thanks again for your reviews on this and other documents, Peter!

Jari



signature.asc
Description: Message signed with OpenPGP using GPGMail
___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art