date:20151014

Re: [Gen-art] Gen-ART Last Call review of draft-ietf-pcp-port-set-10

2015-10-14 Thread Meral Shirazipour

Hi,
  Thank you Mohamed, I am ok with the clarifications and changes.

Best,
Meral

> -Original Message-
> From: mohamed.boucad...@orange.com
> [mailto:mohamed.boucad...@orange.com]
> Sent: Tuesday, October 13, 2015 11:32 PM
> To: Meral Shirazipour
> Cc: draft-ietf-pcp-port-set@tools.ietf.org; gen-art@ietf.org
> Subject: RE: Gen-ART Last Call review of draft-ietf-pcp-port-set-10
> 
> Hi Miral,
> 
> Please see inline.
> 
> Cheers,
> Med
> 
> > -Message d'origine-
> > De : Meral Shirazipour [mailto:meral.shirazip...@ericsson.com]
> > Envoyé : mardi 13 octobre 2015 18:31
> > À : BOUCADAIR Mohamed IMT/OLN
> > Cc : draft-ietf-pcp-port-set@tools.ietf.org; gen-art@ietf.org
> > Objet : RE: Gen-ART Last Call review of draft-ietf-pcp-port-set-10
> >
> > Hi,
> >   Many thanks for the clarifications. Please see inline.
> >
> > Best,
> > Meral
> >
> > > -Original Message-
> > > From: mohamed.boucad...@orange.com
> > > [mailto:mohamed.boucad...@orange.com]
> > > Sent: Tuesday, October 13, 2015 4:42 AM
> > > To: Meral Shirazipour; draft-ietf-pcp-port-set@tools.ietf.org;
> > > gen- a...@ietf.org
> > > Subject: RE: Gen-ART Last Call review of draft-ietf-pcp-port-set-10
> > >
> > > Dear Meral,
> > >
> > > Many thanks for the review.
> > >
> > > Please see inline.
> > >
> > > Cheers,
> > > Med
> > >
> > > > -Message d'origine-
> > > > De : Meral Shirazipour [mailto:meral.shirazip...@ericsson.com]
> > > > Envoyé : lundi 12 octobre 2015 07:49 À :
> > > > draft-ietf-pcp-port-set@tools.ietf.org; gen-art@ietf.org Objet
> > > > : Gen-ART Last Call review of draft-ietf-pcp-port-set-10
> > > >
> > > > 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-pcp-port-set-10
> > > > Reviewer: Meral Shirazipour
> > > > Review Date: 2015-10-10
> > > > IETF LC End Date:  2015-10-14
> > > > IESG Telechat date: NA
> > > >
> > > >
> > > > Summary:
> > > > This draft is ready to be published as Standards Track RFC but I
> > > > have some comments.
> > > >
> > > >
> > > > Major issues:
> > > > N/A
> > > >
> > > > Minor issues:
> > > > -[Page 7], Section 4.1, "If the PCP Client does not know the exact
> > > > number of ports its requires, it MAY then set the Port Set Size to
> > > > 0x, indicating that it is willing to accept as many ports as
> > > > the PCP server can offer."
> > > > Question/clarification to add: Mention if there a mechanism where
> > > > the server will know which of the mapped ports are going to be
> > > > used by the client? and which mappings can be discarded/reused in
> > > > a subsequent request.
> > > >
> > >
> > > [Med] I'm not sure to get your point, especially the link with the
> > sentence
> > > you quoted. But fwiw policies about granted port ranges (size),
> > > ports to
> > be
> > > excluded from assignment, etc. are implementation-specific. These
> > > are similar to the behavior of the PCP server assigning single port
> > > numbers (RFC6887). If the question is about renewal and/or port
> > > overlap, the
> > behavior
> > > is called out in Section 4.4.
> > >
> >
> > [MSh] Sorry I was a bit unclear here. I was wondering what happens if
> > the client asks with 0x, receives e.g. 100 ports but only uses 20 of 
> > them.
> > What happens to the rest? Would they be unused until the next renewal?
> > If so efficiency is not affected?
> > [please also see the thread reply by Simon]
> 
> [Med] Thank you for clarifying. The size of port ranges that are assigned to
> PCP clients is deployment-specific. Operators will need to tune the maximum
> size of the port sets to be assigned taking into account various inputs such 
> as:
> optimize the use of the shared addresses, reduce the amount of pcp
> messages, etc. Of course, efficiency will depend on the size of the assigned
> port set and the actual usage from this set. This is exactly the same issue 
> with
> setting a port quota.
> 
> FWIW, below is provided a sample YANG excerpt to configure the port set
> feature in a PCP server.
> 
>grouping port-set-option {
>description
> "PORT_SET option.";
> 
>leaf port-set-enable {
>   type boolean;
>   description
>  "Enable/disable PORT_SET option.";
>}
> 
>leaf default-port-set-size {
>   type uint16;
>   description
>  "Indicates the default size of a port set.";
>}
> 
>leaf maximum-port-set-size {
>   type uint16;
>   description
>  "Indicates the maximum size of a port set.";
>}
>}
> 
> It is up to each operator to set those parameters. Traffic analyses are 
> likely to
> help operators to set the appropriate values.
> 
> The

[Gen-art] Gen-ART Review of draft-ietf-lisp-impact-04

2015-10-14 Thread Russ Housley

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

Please resolve these comments along with any other Last Call comments
you may receive.

Document: draft-ietf-lisp-impact-04
Reviewer: Russ Housley
Review Date: 2015-10-14
IETF LC End Date: 2015-10-19
IESG Telechat date: unknown

Summary:  Almost Ready.


Major Concerns:

Section 3 says: "[KIF13] and [CDLC] explore different EDI prefix space
sizes, and still show results that are consistent and equivalent to the
above assumptions."  It seems like it would be valuable to include a
sentence or two about the way that EDI space is obtained.


Minor Concerns:

I found the Introduction and LISP in a nutshell sections a bit too
much like marketing material.  I think the document would be better
if the tone was more like an engineering analysis.

Perhaps this paragraph can be moved to the top:

   An introduction to LISP can be found in [RFC7215].  The LISP
   specifications are given in [RFC6830], [RFC6833],
   [I-D.ietf-lisp-ddt], [RFC6836], [RFC6832], [RFC6834].

Section 5 has very little content on "business models".  There is some,
but not much.  It seems odd that it appears in the section heading.


Other Comments:

Please spell out "DPI" and "DFZ" on first use.

Section 4 says: "Without LISP, operators are forced to centralize
service anchors in custom built boxes."  This seems a bit too strong.
Perhaps: "Without LISP, operators centralize service anchors."

Section 4.1: s/(non-LISP)routing/(non-LISP) routing/

___
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-pcp-port-set-10

2015-10-14 Thread mohamed.boucadair

Hi Miral,

Please see inline.

Cheers,
Med

> -Message d'origine-
> De : Meral Shirazipour [mailto:meral.shirazip...@ericsson.com]
> Envoyé : mardi 13 octobre 2015 18:31
> À : BOUCADAIR Mohamed IMT/OLN
> Cc : draft-ietf-pcp-port-set@tools.ietf.org; gen-art@ietf.org
> Objet : RE: Gen-ART Last Call review of draft-ietf-pcp-port-set-10
> 
> Hi,
>   Many thanks for the clarifications. Please see inline.
> 
> Best,
> Meral
> 
> > -Original Message-
> > From: mohamed.boucad...@orange.com
> > [mailto:mohamed.boucad...@orange.com]
> > Sent: Tuesday, October 13, 2015 4:42 AM
> > To: Meral Shirazipour; draft-ietf-pcp-port-set@tools.ietf.org; gen-
> > a...@ietf.org
> > Subject: RE: Gen-ART Last Call review of draft-ietf-pcp-port-set-10
> >
> > Dear Meral,
> >
> > Many thanks for the review.
> >
> > Please see inline.
> >
> > Cheers,
> > Med
> >
> > > -Message d'origine-
> > > De : Meral Shirazipour [mailto:meral.shirazip...@ericsson.com]
> > > Envoyé : lundi 12 octobre 2015 07:49
> > > À : draft-ietf-pcp-port-set@tools.ietf.org; gen-art@ietf.org Objet
> > > : Gen-ART Last Call review of draft-ietf-pcp-port-set-10
> > >
> > > 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-pcp-port-set-10
> > > Reviewer: Meral Shirazipour
> > > Review Date: 2015-10-10
> > > IETF LC End Date:  2015-10-14
> > > IESG Telechat date: NA
> > >
> > >
> > > Summary:
> > > This draft is ready to be published as Standards Track RFC but I have
> > > some comments.
> > >
> > >
> > > Major issues:
> > > N/A
> > >
> > > Minor issues:
> > > -[Page 7], Section 4.1, "If the PCP Client does not know the exact
> > > number of ports its requires, it MAY then set the Port Set Size to
> > > 0x, indicating that it is willing to accept as many ports as the
> > > PCP server can offer."
> > > Question/clarification to add: Mention if there a mechanism where the
> > > server will know which of the mapped ports are going to be used by the
> > > client? and which mappings can be discarded/reused in a subsequent
> > > request.
> > >
> >
> > [Med] I'm not sure to get your point, especially the link with the
> sentence
> > you quoted. But fwiw policies about granted port ranges (size), ports to
> be
> > excluded from assignment, etc. are implementation-specific. These are
> > similar to the behavior of the PCP server assigning single port numbers
> > (RFC6887). If the question is about renewal and/or port overlap, the
> behavior
> > is called out in Section 4.4.
> >
> 
> [MSh] Sorry I was a bit unclear here. I was wondering what happens if the
> client asks with 0x, receives e.g. 100 ports but only uses 20 of them.
> What happens to the rest? Would they be unused until the next renewal? If
> so efficiency is not affected?
> [please also see the thread reply by Simon]

[Med] Thank you for clarifying. The size of port ranges that are assigned to 
PCP clients is deployment-specific. Operators will need to tune the maximum 
size of the port sets to be assigned taking into account various inputs such 
as: optimize the use of the shared addresses, reduce the amount of pcp 
messages, etc. Of course, efficiency will depend on the size of the assigned 
port set and the actual usage from this set. This is exactly the same issue 
with setting a port quota. 

FWIW, below is provided a sample YANG excerpt to configure the port set feature 
in a PCP server. 

   grouping port-set-option {
   description
"PORT_SET option.";

   leaf port-set-enable {
  type boolean;
  description
 "Enable/disable PORT_SET option.";
   }

   leaf default-port-set-size {
  type uint16;
  description
 "Indicates the default size of a port set.";
   }

   leaf maximum-port-set-size {
  type uint16;
  description
 "Indicates the maximum size of a port set.";
   }
   }

It is up to each operator to set those parameters. Traffic analyses are likely 
to help operators to set the appropriate values. 

The port-set draft does not need to deal with these aspects as those are 
deployment-specific. 

> 
> > >
> > > Nits/editorial comments:
> > > -[Page 6], "In particular, the PREFER_FAILURE option MUST NOT be
> > > present in a request that contains a PORT_SET option.".
> > > Suggestion: Please add a sentence after this one suggesting why
> > > PREFER_FAILURE option MUST NOT be used. It was not clear to me until I
> > > read the rest of the draft...although I am still not sure why this
> > > behavior is to be a MUST NOT.
> >
> > [Med] PREFER_FAILURE was specifically designed for the interworking with
> > UPnP IGD:1 (RF6970). The rationale why it should not be used by other
> PCP
>

Re: [Gen-art] Review: draft-ietf-pals-mpls-tp-mac-wd

2015-10-14 Thread Shah, Himanshu

Can you please re-send this. My entrust can not "decode" MIME format or 
something like that error.
I only see blank (no text) email and no attachments..

Thanks,
Himanshu

From: Ralph Droms (rdroms) [mailto:rdr...@cisco.com]
Sent: Wednesday, October 14, 2015 3:56 PM
To: A. Jean Mahoney; General Area Review Team; 
draft-ietf-pals-mpls-tp-mac-wd@ietf.org
Cc: Ralph Droms (rdroms)
Subject: Review: draft-ietf-pals-mpls-tp-mac-wd

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

[Gen-art] Review: draft-ietf-pals-mpls-tp-mac-wd

2015-10-14 Thread Ralph Droms (rdroms)

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-pals-mpls-tp-mac-wd-02, "MAC Address Withdrawal over 
Static Pseudowire"
Reviewer: Ralph Droms
Review Date: 2015-10-14
IETF LC End Date: 2015-10-19
IESG Telechat date: (if known) N/A

Summary:

This draft is on the right track but has open issues, described in the review.


Major issues:

While this document is describing a straightforward adaptation of previously 
defined standards to statically provisioned PWs, in my opinion an implementor 
would not necessarily be able to construct a fully interoperable implementation 
from this document.  There are several sections of the document that are not 
clear in their description of how to use mechanisms from referenced documents 
in this standard.

If it appears that some of my comments are overly finicky, I'll agree that the 
correct implementation could probably be deduced from the text in most cases.  
That is, I didn't find many outright errors or inconsistencies.  Many of my 
comments took a lot of paging back and forth, reading of referenced documents 
and head-scratching, which, in my experience, can lead to implementations that 
don't interoperate.

Section 1:

  When the number of MAC addresses to be
  removed is large, the empty MAC List TLV may be used.  The empty MAC
  List TLV signifies wildcard MAC Address withdrawl.

This text seems to be the only reference to the processing of an empty MAC List 
TLV.  Specification of how the protocol works doesn't belong in the 
Introduction, and "wildcard MAC Address withdrawal" could certainly use some 
more explanation.

Section 3:

  The PW OAM message header is exactly the same as what is
  defined in [RFC6478].

Is this statement really true?  The MAC Address Withdraw header seems to 
replace the "Refresh Timer" field with a "Reserved" field, and adds a new "R" 
flag.  The statement might be misleading to an implementor.

  a MAC address withdraw OAM message MUST contain a
  "Sequence Number TLV" otherwise the entire message is dropped.

Is the "Sequence Number TLV" required to be the first TLV in the message?  Are 
the TLVs required to appear in any particular order?

  A single bit (called A-bit) is set to indicate if a MAC withdraw
  message is for ACK.  Also, ACK does not include MAC TLV(s).

Does this mean that the message is an ACK if the A-bit is set?  Can an ACK 
contain a "Sequence Number" TLV?

  Only half of the sequence number space is used.  Modular arithmetic
  is used to detect wrapping of sequence number.  When sequence number
  wraps, all MAC addresses are flushed and the sequence number is
  reset.  The 16-bit sequence number handling is described in
  [RFC4385]. This document uses 32-bits sequence numbers and hence
  sequence number in half the number space (i.e. 31-bits or ~2billion)
  is considered in the valid receive range.

This paragraph is not at all clear to me. Reading section 4 of RFC 4385 helped 
but left me unsure about how my understanding of how to extend the sequence 
number mechanism to 32 bits corresponds to the expectations of this document.

Section 4.1:

  Each PW is associated with a counter to keep track of the sequence
  number of the transmitted MAC withdrawal messages.  Whenever a node
  sends a new set of MAC TLVs, it increments the transmitted sequence
  number counter, and include the new sequence number in the message.
  The transmit sequence number is initialized to 1 at the onset.

I'm pretty sure this is supposed to mean that the sequence number in the first 
message is 1.  The text could be interpreted to mean that the counter is 
initialized to 1 and then incremented to 2 when sending the first message.

  The retransmission MUST be
  ceased anytime when ACK is received or after three retries.  This
  avoids unended retransmissions in the absence of acknowledgements.
  Since retransmission time interval and the maximum number of retries
  is local configuration of the sender node, it is up to the
  implementers to pick a discipline.

Is the maximum number of retransmissions 3 or is it locally configured?  Is the 
default 3?

  The 'R' reset bit is set in the first MAC withdraw
  to notify the remote peer to reset the send and receive sequence
  numbers.  The 'R' bit must be cleared in subsequent MAC withdraw
  messages after the acknowledgement is received

"First" as in "first message after reset or restart or ???  Would it be better 
to say "The R-bit is set in a message when one peer needs to force the remote 
peer to reset its send and receive sequence numbers"?  Does the device sending 
the message with the R-bit use a sequence number of 1 in that message, and 
expect the next message from

[Gen-art] Review: draft-ietf-pals-mpls-tp-mac-wd

2015-10-14 Thread Ralph Droms (rdroms)

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-pals-mpls-tp-mac-wd-02, "MAC Address Withdrawal over 
Static Pseudowire"
Reviewer: Ralph Droms
Review Date: 2015-10-14
IETF LC End Date: 2015-10-19
IESG Telechat date: (if known) N/A

Summary:

This draft is on the right track but has open issues, described in the review.


Major issues:

While this document is describing a straightforward adaptation of previously 
defined standards to statically provisioned PWs, in my opinion an implementor 
would not necessarily be able to construct a fully interoperable implementation 
from this document.  There are several sections of the document that are not 
clear in their description of how to use mechanisms from referenced documents 
in this standard.

If it appears that some of my comments are overly finicky, I'll agree that the 
correct implementation could probably be deduced from the text in most cases.  
That is, I didn't find many outright errors or inconsistencies.  Many of my 
comments took a lot of paging back and forth, reading of referenced documents 
and head-scratching, which, in my experience, can lead to implementations that 
don't interoperate.

Section 1:

   When the number of MAC addresses to be
   removed is large, the empty MAC List TLV may be used.  The empty MAC
   List TLV signifies wildcard MAC Address withdrawl.

This text seems to be the only reference to the processing of an empty MAC List 
TLV.  Specification of how the protocol works doesn't belong in the 
Introduction, and "wildcard MAC Address withdrawal" could certainly use some 
more explanation.

Section 3:

   The PW OAM message header is exactly the same as what is
   defined in [RFC6478].

Is this statement really true?  The MAC Address Withdraw header seems to 
replace the "Refresh Timer" field with a "Reserved" field, and adds a new "R" 
flag.  The statement might be misleading to an implementor.

   a MAC address withdraw OAM message MUST contain a
   "Sequence Number TLV" otherwise the entire message is dropped.

Is the "Sequence Number TLV" required to be the first TLV in the message?  Are 
the TLVs required to appear in any particular order?

   A single bit (called A-bit) is set to indicate if a MAC withdraw
   message is for ACK.  Also, ACK does not include MAC TLV(s).

Does this mean that the message is an ACK if the A-bit is set?  Can an ACK 
contain a "Sequence Number" TLV?

   Only half of the sequence number space is used.  Modular arithmetic
   is used to detect wrapping of sequence number.  When sequence number
   wraps, all MAC addresses are flushed and the sequence number is
   reset.  The 16-bit sequence number handling is described in
   [RFC4385]. This document uses 32-bits sequence numbers and hence
   sequence number in half the number space (i.e. 31-bits or ~2billion)
   is considered in the valid receive range.

This paragraph is not at all clear to me. Reading section 4 of RFC 4385 helped 
but left me unsure about how my understanding of how to extend the sequence 
number mechanism to 32 bits corresponds to the expectations of this document.

Section 4.1:

   Each PW is associated with a counter to keep track of the sequence
   number of the transmitted MAC withdrawal messages.  Whenever a node
   sends a new set of MAC TLVs, it increments the transmitted sequence
   number counter, and include the new sequence number in the message.
   The transmit sequence number is initialized to 1 at the onset.

I'm pretty sure this is supposed to mean that the sequence number in the first 
message is 1.  The text could be interpreted to mean that the counter is 
initialized to 1 and then incremented to 2 when sending the first message.

   The retransmission MUST be
   ceased anytime when ACK is received or after three retries.  This
   avoids unended retransmissions in the absence of acknowledgements.
   Since retransmission time interval and the maximum number of retries
   is local configuration of the sender node, it is up to the
   implementers to pick a discipline.

Is the maximum number of retransmissions 3 or is it locally configured?  Is the 
default 3?

   The 'R' reset bit is set in the first MAC withdraw
   to notify the remote peer to reset the send and receive sequence
   numbers.  The 'R' bit must be cleared in subsequent MAC withdraw
   messages after the acknowledgement is received

"First" as in "first message after reset or restart or ???  Would it be better 
to say "The R-bit is set in a message when one peer needs to force the remote 
peer to reset its send and receive sequence numbers"?  Does the device sending 
the message with the R-bit use a sequence number of 1 in that message, and

[Gen-art] Gen-ART review of draft-ietf-grow-bmp-15

2015-10-14 Thread Vijay K. Gurbani


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

Please resolve these comments along with any other Last Call comments
you may receive.

Document: draft-ietf-grow-bmp-15
Reviewer: Vijay K. Gurbani
Review Date: Oct-14-2015
IETF LC End Date: Not known
IESG Telechat date: Oct-15-2015

This document is ready as a Proposed Standard with two minor nits.

Major: 0
Minor: 2
Nits:  0

Minor:
- S3.2,, first paragraph: "No message is ever sent from the monitoring
   station to the monitored router."
 You mean "No BMP message is ever sent from the monitoring station to
 the monitored router."?  I suspect that the monitoring station can send
 TCP messages (SYN, ACK, etc.) to the monitored router in order to open
 up the TCP connection, no?

- S3.2, last paragraph: "If the monitoring station intends to end or
   restart BMP processing, it simply drops the connection, optionally
   with a Termination message."
 The monitoring station cannot send a (BMP?) message to the monitored
 router, right?  If so, I don't understand the utility of the
 Termination method above.

Thanks,

- vijay
--
Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent
1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60563 (USA)
Email: vkg@{bell-labs.com,acm.org} / vijay.gurb...@alcatel-lucent.com
Web: http://ect.bell-labs.com/who/vkg/  | Calendar: http://goo.gl/x3Ogq

___
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-v6ops-siit-eam-01

2015-10-14 Thread Jari Arkko

Thanks for the review, Dan!

On this:

> 
>When translating a packet between IPv4 and IPv6, an SIIT
>implementation MUST individually translate each IP address it
>encounters in the packet's IP headers (including any IP headers
>contained within ICMP errors) according to Section 3.3, except for
>any address for which Section 4 explicitly states that the EAM
>algorithm MUST NOT be used.

I think this makes sense, and I at least feel this is better text than the 
original. Thanks.

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-grow-bmp-15

2015-10-14 Thread Jari Arkko

Thanks for the review, Vijay. Good questions. Do the authors have an answer?

Jari

On 15 Oct 2015, at 00:49, Vijay K. Gurbani  wrote:

> I am the assigned Gen-ART reviewer for this draft. For background on
> Gen-ART, please see the FAQ at
> .
> 
> Please resolve these comments along with any other Last Call comments
> you may receive.
> 
> Document: draft-ietf-grow-bmp-15
> Reviewer: Vijay K. Gurbani
> Review Date: Oct-14-2015
> IETF LC End Date: Not known
> IESG Telechat date: Oct-15-2015
> 
> This document is ready as a Proposed Standard with two minor nits.
> 
> Major: 0
> Minor: 2
> Nits:  0
> 
> Minor:
> - S3.2,, first paragraph: "No message is ever sent from the monitoring
>   station to the monitored router."
> You mean "No BMP message is ever sent from the monitoring station to
> the monitored router."?  I suspect that the monitoring station can send
> TCP messages (SYN, ACK, etc.) to the monitored router in order to open
> up the TCP connection, no?
> 
> - S3.2, last paragraph: "If the monitoring station intends to end or
>   restart BMP processing, it simply drops the connection, optionally
>   with a Termination message."
> The monitoring station cannot send a (BMP?) message to the monitored
> router, right?  If so, I don't understand the utility of the
> Termination method above.
> 
> Thanks,
> 
> - vijay
> --
> Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent
> 1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60563 (USA)
> Email: vkg@{bell-labs.com,acm.org} / vijay.gurb...@alcatel-lucent.com
> Web: http://ect.bell-labs.com/who/vkg/  | Calendar: http://goo.gl/x3Ogq
> 
> ___
> 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-mpls-self-ping-04

2015-10-14 Thread Jari Arkko

Thank you Russ, thank you Ron.

Jari

On 29 Sep 2015, at 17:38, Ronald Bonica  wrote:

> Russ,
> 
> Agree on both points. I have:
> 
> - removed the word "unique"
> - moved Section 6 to an appendix
> 
> Thanks for the review.
> 
>   Ron
> 
> 
>> -Original Message-
>> From: Russ Housley [mailto:hous...@vigilsec.com]
>> Sent: Friday, September 25, 2015 10:30 AM
>> To: draft-ietf-mpls-self-ping@ietf.org
>> Cc: IETF Gen-ART ; IETF 
>> Subject: Gen-ART Review of draft-ietf-mpls-self-ping-04
>> 
>> I am the assigned Gen-ART reviewer for this draft. For background on Gen-
>> ART, please see the FAQ at
>> .
>> 
>> Please resolve these comments along with any other Last Call comments you
>> may receive.
>> 
>> Document: draft-ietf-mpls-self-ping-04
>> Reviewer: Russ Housley
>> Review Date: 2014-09-25
>> IETF LC End Date: 2014-10-02
>> IESG Telechat date: unknown
>> 
>> Summary:  Ready.
>> 
>> Major Concerns:  None.
>> 
>> Minor Concerns:  None.
>> 
>> Other Comments:
>> 
>> At the end of Section 1, the document says: "Each protocol listens on its own
>> UDP port and executes its own unique procedures."  What does "unique"
>> mean here?  What changes if "unique" is dropped from this sentence?
>> 
>> Would it be more obvious to the reader the purpose of Section 6 if it were
>> turned into an appendix?
> 
> ___
> 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-idr-ls-distribution-10

2015-10-14 Thread Jari Arkko

(belated) thanks for the review and the fixes. the document is on tomorrow’s 
IESG telechat and i have balloted no-objection.

jari

On 04 Jun 2015, at 19:55, Hannes Gredler  wrote:

> alexey,
> 
> thanks for your comments - have incorporated them - diff is here:
> https://github.com/hannesgredler/draft-ietf-idr-ls-distribution/commit/4c5e120d9679006f553320928ba867ed9612c41f
> 
> /hannes
> 
> On Sun, May 10, 2015 at 08:51:04PM +0100, Adrian Farrel wrote:
> |Link: [1]File-List
> |
> |Forwarding on behalf of Alexey.
> |
> |
> |
> |From: Alexey Melnikov [mailto:alexey.melni...@isode.com]
> |Sent: 10 May 2015 17:22
> |To: adr...@olddog.co.uk
> |Subject: Fwd: [Gen-art] Gen-ART telechat review of
> |draft-ietf-idr-ls-distribution-10
> |
> |
> |
> |Hi Adrian,
> |I am having some problems with the tools.ietf.org alias expansion. Can 
> you
> |forward to your co-editors?
> |
> | Original Message 
> |
> |Subject: [Gen-art] Gen-ART telechat review of
> | draft-ietf-idr-ls-distribution-10
> |   Date: Sun, 10 May 2015 17:18:12 +0100
> |   From: Alexey Melnikov [2]
> | To: [3]draft-ietf-idr-ls-distribution@tools.ietf.org, General
> | Area Review Team [4]
> |
> |
> |
> |  [Resending]
> |
> |
> |
> |  I am the assigned Gen-ART reviewer for this draft. For background on
> |
> |  Gen-ART, please see the FAQ at
> |
> |  [5]< http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.
> |
> |
> |
> |  Please wait for direction from your document shepherd
> |
> |  or AD before posting a new version of the draft.
> |
> |
> |
> |  Document: draft-ietf-idr-ls-distribution-10.txt
> |
> |  Reviewer: Alexey Melnikov
> |
> |  Review Date: 2015-05-10
> |
> |  IETF LC End Date: 2015-04-08
> |
> |  IESG Telechat date: N/A
> |
> |
> |
> |  My apologies for the late review of this document.
> |
> |
> |
> |  Summary: Ready with nits
> |
> |
> |
> |
> |
> |  Minor (but some of these might be more serious):
> |
> |
> |
> |  In 6.2.2:
> |
> |
> |
> |  If an implementation of BGP-LS detects a malformed attribute, then it
> |
> |  SHOULD use the 'Attribute Discard' action as per
> |
> |  [I-D.ietf-idr-error-handling] Section 2.
> |
> |
> |
> |  This needs to be a Normative reference. Or you can keep it as
> |
> |  Informative, if you change the sentence not to use RFC 2119 language.
> |
> |
> |
> |  In 3.3.1.1 - does this need a new IANA registry? (I am fine if you think
> |
> |  you don't).
> |
> |
> |
> |  In 3.3.1.3/3.3.2.7 - what is "subset of the FQDN"?
> |
> |
> |
> |  In 3.3.2.3:
> |
> |
> |
> | The TE Default Metric TLV carries the TE-metric for this link.
> |
> | The length of this TLV is fixed at 4 octets.
> |
> |
> |
> |  I am probably showing my ignorance, but is the term "TE-metric" defined
> |
> |  somewhere? The description below suggests it has substructure, which I
> |
> |  don't know anything about.
> |
> |
> |
> |  If a source protocol (e.g.
> |
> |  IS-IS) does not support a Metric width of 32 bits then the high
> |
> |  order octet MUST be set to zero.
> |
> |
> |
> |  Best Regards,
> |
> |  Alexey
> |
> |
> |
> |  ___
> |
> |  Gen-art mailing list
> |
> |  [6]Gen-art@ietf.org
> |
> |  [7]https://www.ietf.org/mailman/listinfo/gen-art
> |
> |
> |
> |
> |
> | References
> |
> |Visible links
> |1. 
> file:///var/folders/cf/mshm9h8557j_j4kxtypy1gx8gn/T/cid:filelist.xml@01D08B62.75F17A40
> |2. mailto:alexey.melni...@isode.com
> |3. mailto:draft-ietf-idr-ls-distribution@tools.ietf.org
> |4. mailto:gen-art@ietf.org
> |5. http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq
> |6. mailto:Gen-art@ietf.org
> |7. 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 LC review of draft-ietf-trill-cmt-08

2015-10-14 Thread Jari Arkko

Thank you, both of you.

Jari

On 07 Oct 2015, at 21:26, Donald Eastlake  wrote:

> I believe the -10 version posted today resolves your comments.
> 
> Thanks,
> Donald
> =
>  Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
>  155 Beaver Street, Milford, MA 01757 USA
>  d3e...@gmail.com
> 
> On Fri, Oct 2, 2015 at 11:27 AM, Roni Even  wrote:
> I am the assigned Gen-ART reviewer for this draft. For background on Gen-ART, 
> please see the FAQ at 
> .
> 
> Please resolve these comments along with any other Last Call comments you may 
> receive.
> 
> Document:  draft-ietf-trill-cmt-08
> 
> Reviewer: Roni Even
> 
> Review Date:2015–10-2
> 
> IETF LC End Date: 2015–10-5
> 
> IESG Telechat date:
> 
> 
> 
> Summary: This draft is ready for publication as a Standard Track  RFC.
> 
> 
> 
> 
> 
> Major issues:
> 
> 
> 
> 
> 
> Minor issues:
> 
> 
> 
> 
> 
> Nits/editorial comments:
> 
> In section 4.1 last paragraph “that are do not support” should be “that do 
> not support”
> 
> 
> 
> 
> 
> 
> 
> 
> ___
> 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 Last Call review of draft-ietf-pcp-port-set-10

2015-10-14 Thread mohamed.boucadair

Hi Meral,

Thank you again for your review. 

FWIW, the changes you requested have been included in the new revision 
available at: https://tools.ietf.org/html/draft-ietf-pcp-port-set-11 
Diff:   https://www.ietf.org/rfcdiff?url2=draft-ietf-pcp-port-set-11 

Cheers,
Med

> -Message d'origine-
> De : Meral Shirazipour [mailto:meral.shirazip...@ericsson.com]
> Envoyé : mercredi 14 octobre 2015 17:41
> À : BOUCADAIR Mohamed IMT/OLN
> Cc : draft-ietf-pcp-port-set@tools.ietf.org; gen-art@ietf.org
> Objet : RE: Gen-ART Last Call review of draft-ietf-pcp-port-set-10
> 
> Hi,
>   Thank you Mohamed, I am ok with the clarifications and changes.
> 
> Best,
> Meral
> 
> > -Original Message-
> > From: mohamed.boucad...@orange.com
> > [mailto:mohamed.boucad...@orange.com]
> > Sent: Tuesday, October 13, 2015 11:32 PM
> > To: Meral Shirazipour
> > Cc: draft-ietf-pcp-port-set@tools.ietf.org; gen-art@ietf.org
> > Subject: RE: Gen-ART Last Call review of draft-ietf-pcp-port-set-10
> >
> > Hi Miral,
> >
> > Please see inline.
> >
> > Cheers,
> > Med
> >
> > > -Message d'origine-
> > > De : Meral Shirazipour [mailto:meral.shirazip...@ericsson.com]
> > > Envoyé : mardi 13 octobre 2015 18:31
> > > À : BOUCADAIR Mohamed IMT/OLN
> > > Cc : draft-ietf-pcp-port-set@tools.ietf.org; gen-art@ietf.org
> > > Objet : RE: Gen-ART Last Call review of draft-ietf-pcp-port-set-10
> > >
> > > Hi,
> > >   Many thanks for the clarifications. Please see inline.
> > >
> > > Best,
> > > Meral
> > >
> > > > -Original Message-
> > > > From: mohamed.boucad...@orange.com
> > > > [mailto:mohamed.boucad...@orange.com]
> > > > Sent: Tuesday, October 13, 2015 4:42 AM
> > > > To: Meral Shirazipour; draft-ietf-pcp-port-set@tools.ietf.org;
> > > > gen- a...@ietf.org
> > > > Subject: RE: Gen-ART Last Call review of draft-ietf-pcp-port-set-10
> > > >
> > > > Dear Meral,
> > > >
> > > > Many thanks for the review.
> > > >
> > > > Please see inline.
> > > >
> > > > Cheers,
> > > > Med
> > > >
> > > > > -Message d'origine-
> > > > > De : Meral Shirazipour [mailto:meral.shirazip...@ericsson.com]
> > > > > Envoyé : lundi 12 octobre 2015 07:49 À :
> > > > > draft-ietf-pcp-port-set@tools.ietf.org; gen-art@ietf.org Objet
> > > > > : Gen-ART Last Call review of draft-ietf-pcp-port-set-10
> > > > >
> > > > > 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-pcp-port-set-10
> > > > > Reviewer: Meral Shirazipour
> > > > > Review Date: 2015-10-10
> > > > > IETF LC End Date:  2015-10-14
> > > > > IESG Telechat date: NA
> > > > >
> > > > >
> > > > > Summary:
> > > > > This draft is ready to be published as Standards Track RFC but I
> > > > > have some comments.
> > > > >
> > > > >
> > > > > Major issues:
> > > > > N/A
> > > > >
> > > > > Minor issues:
> > > > > -[Page 7], Section 4.1, "If the PCP Client does not know the exact
> > > > > number of ports its requires, it MAY then set the Port Set Size to
> > > > > 0x, indicating that it is willing to accept as many ports as
> > > > > the PCP server can offer."
> > > > > Question/clarification to add: Mention if there a mechanism where
> > > > > the server will know which of the mapped ports are going to be
> > > > > used by the client? and which mappings can be discarded/reused in
> > > > > a subsequent request.
> > > > >
> > > >
> > > > [Med] I'm not sure to get your point, especially the link with the
> > > sentence
> > > > you quoted. But fwiw policies about granted port ranges (size),
> > > > ports to
> > > be
> > > > excluded from assignment, etc. are implementation-specific. These
> > > > are similar to the behavior of the PCP server assigning single port
> > > > numbers (RFC6887). If the question is about renewal and/or port
> > > > overlap, the
> > > behavior
> > > > is called out in Section 4.4.
> > > >
> > >
> > > [MSh] Sorry I was a bit unclear here. I was wondering what happens if
> > > the client asks with 0x, receives e.g. 100 ports but only uses 20
> of them.
> > > What happens to the rest? Would they be unused until the next renewal?
> > > If so efficiency is not affected?
> > > [please also see the thread reply by Simon]
> >
> > [Med] Thank you for clarifying. The size of port ranges that are
> assigned to
> > PCP clients is deployment-specific. Operators will need to tune the
> maximum
> > size of the port sets to be assigned taking into account various inputs
> such as:
> > optimize the use of the shared addresses, reduce the amount of pcp
> > messages, etc. Of course, efficiency will depend on the size of the
> assigned
> > port set and the actual usage from this set. This is exactly the same
> issue with
> > setting a port quota.
> >
> >

Re: [Gen-art] Gen-ART Last Call review of draft-ietf-pcp-port-set-10

[Gen-art] Gen-ART Review of draft-ietf-lisp-impact-04

Re: [Gen-art] Gen-ART Last Call review of draft-ietf-pcp-port-set-10

Re: [Gen-art] Review: draft-ietf-pals-mpls-tp-mac-wd

[Gen-art] Review: draft-ietf-pals-mpls-tp-mac-wd

[Gen-art] Review: draft-ietf-pals-mpls-tp-mac-wd

[Gen-art] Gen-ART review of draft-ietf-grow-bmp-15

Re: [Gen-art] Gen-ART review of draft-ietf-v6ops-siit-eam-01

Re: [Gen-art] Gen-ART review of draft-ietf-grow-bmp-15

Re: [Gen-art] Gen-ART Review of draft-ietf-mpls-self-ping-04

Re: [Gen-art] Gen-ART telechat review of draft-ietf-idr-ls-distribution-10

Re: [Gen-art] Gen-ART LC review of draft-ietf-trill-cmt-08

Re: [Gen-art] Gen-ART Last Call review of draft-ietf-pcp-port-set-10

13 matches

Site Navigation

Mail list logo

Footer information