Re: [Gen-art] Genart last call review of draft-ietf-mpls-rfc8287-len-clarification-02

[Carlos Pignataro (cpignata)]

Hi, Ines, Many thanks for your very useful review!

Thanks Alissa for flagging this.

Please find some follow-up comments inline.

> On Aug 6, 2019, at 3:11 PM, Alissa Cooper  wrote:
> 
> Ines, thanks for your review. I entered a DISCUSS ballot to get the figure 
> fixed in Section 4.2.
> 
> Alissa
> 
> 
>> On Jul 30, 2019, at 8:11 AM, Ines Robles via Datatracker  
>> wrote:
>> 
>> Reviewer: Ines Robles
>> Review result: Ready with Issues
>> 
>> 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-mpls-rfc8287-len-clarification-02
>> Reviewer: Ines Robles
>> Review Date: 2019-07-30
>> IETF LC End Date: 2019-07-31
>> IESG Telechat date: Not scheduled for a telechat
>> 
>> Summary:
>> 
>> I believe the draft is technically good. This document is well written.
>> 
>> The document updates RFC8287 by clarifying the length for the following 
>> Segment
>> ID Sub-TLVs: IPv4 IGP-Prefix Segment ID Sub-TLV, IPv6 IGP-Prefix Segment ID
>> Sub-TLV and IGP-Adjacency Segment ID Sub-TLV.
>> 
>> There are some minor issues detailed below that should be addressed.
>> 
>> Major issues: Not found
>> 
>> Minor issues:
>> 
>> 1- Section 3 - Requirements notation is not complete, it should be added:  
>> "NOT
>> RECOMMENDED" and "...are to be interpreted as described in BCP 14 [RFC2119]
>> [RFC8174] when, and only when, they appear in all capitals, as shown here.”
>> 

Sure.

>> 2- Figure of Section 4.2: Type = 35 (IPv4 IGP-Prefix SID) ---> Type = 35 
>> (IPv6
>> IGP-Prefix SID)
>> 

Indeed. Great catch and many thanks.

>> 2.1- It would be nice if the figures have a caption where we can point to the
>> figure number, and the figure number is referenced in the text. The same for
>> the table of Section 4.3.
>> 

We had thought about this, and received this comment before also, but since 
this is largely a fix and update to RFC 8287, we want to remain consistent to 
the format used there.

>> 3- Question: What do you think?
>> 
>> I think it would be nice to explain a bit more the length for the different
>> combinations of the table of Section 4.3, e.g. with tables as detailed below:

Thanks for this suggestion. To me, it seems a bit overkill to explain the the 
size of an IPv4 is 4 octets, and the size of an IPv6 is 16 octets, etc. The 
fact that we are including the table seems the right middle-ground for 
readability, thoroughness, and detailed-orientedness.

But thanks for the suggestion.

Best,

Carlos.

>> 
>> +-+---+
>> |Field   | Parallel (octets) |
>> | rfc8287#section-5.3+-+--+--+
>> |   | Any | OSPF | ISIS |
>> +-+-+--+--+
>> |  Local Interface ID|  4  |   4  |   4  |
>> +-+-+--+--+
>> | Remote Interface ID |  4  |   4  |   4  |
>> +-+-+--+--+
>> | Advertising Node Identifier  |  4  |   4  |   6  |
>> +-+-+--+--+
>> |  Receiving Node Identifier |  4  |   4  |   6  |
>> +-+-+--+--+
>> |   Reserved |  2  |   2  |   2  |
>> +-+-+--+--+
>> | Adj. Type + Protocol |  2  |   2  |   2  |
>> +-+-+--+--+
>> |   Sum Total octets =  |  20 |  20  |  24  |
>> +-+-+--+--+
>> 
>> +-+---+
>> |Field|   IPv4 (octets)   |
>> | rfc8287#section-5.3 +-+--+--+
>> || Any | OSPF | ISIS 
>> |
>> +-+-+--+--+
>> |  Local Interface ID |  4  |   4  |   4  |
>> +-+-+--+--+
>> | Remote Interface ID |  4  |   4  |   4  |
>> +-+-+--+--+
>> | Advertising Node Identifier   |  4  |   4  |   6  |
>> +-+-+--+--+
>> |  Receiving Node Identifier |  4  |   4  |   6  |
>> +-+-+--+--+
>> |   Reserved  |  2  |   2  |   2  |
>> +-+-+--+--+
>> | Adj. Type + Protocol |  2  |   2  |   2  |
>> +-

Re: [Gen-art] Genart telechat review of draft-ietf-lime-yang-connectionless-oam-13

[Carlos Pignataro (cpignata)]

Many thanks for your review Elwyn, and for the quick response, Qin!

Thumb typed by Carlos Pignataro.
Excuze typofraphicak errows

On Oct 24, 2017, at 03:21, Qin Wu 
mailto:bill...@huawei.com>> wrote:

Elwyn:
Thank for your valuable comments.
Please see my reply inline below.

-Qin
-邮件原件-
发件人: Elwyn Davies [mailto:elw...@dial.pipex.com]
发送时间: 2017年10月24日 8:42
收件人: gen-art@ietf.org<mailto:gen-art@ietf.org>
抄送: 
draft-ietf-lime-yang-connectionless-oam@ietf.org<mailto:draft-ietf-lime-yang-connectionless-oam@ietf.org>;
 l...@ietf.org<mailto:l...@ietf.org>; i...@ietf.org<mailto:i...@ietf.org>
主题: Genart telechat review of draft-ietf-lime-yang-connectionless-oam-13

Reviewer: Elwyn Davies
Review result: Ready with Issues

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

<https://trac.ietf.org/trac/gen/wiki/GenArtfaq>.

Document: draft-ietf-lime-yang-connectionless-oam-13
Reviewer: Elwyn Davies
Review Date: 2017-10-23
IETF LC End Date: 2017-10-25
IESG Telechat date: 2017-10-26

Summary:Not really ready.  There are several missing references and the English 
needs cleaning up to make the document comprehensible. I found s3 to be almost 
totally opaque.  The fundamental concept of a Test Point needs a proper 
definition in s2 and a clearer introduction in s3.  The concept of 'neighboring 
test points' confused me for some time: I was thinking of neighboring nodes in 
the network whereas what seesm to be meant is a possibility of a multiplicity of

Major issues:
None

Minor issues:
Title and description of model:
The title refers to 'connectionless networks'.  In practice the YANG model 
could be used with both connectionless and connection-oriented communication 
technologies.  I think the intention is to be able to support the management of 
OAM protocols that operate in a connectionless manner (i.e., using 
connectionless *technologies*, as per RFC 7276) rather than connectionless 
networks. In the title - OLD:
 Generic YANG Data Model for Operations, Administration, and
Maintenance(OAM) protocols for Connectionless networks
NEW:
 Generic YANG Data Model for the Management of Operations,
Administration, and Maintenance (OAM) Protocols that
use Connectionless Communications END

[Qin]: Your understanding is correct, the title change in v-13 is based on one 
proposal from latest comments, I agree with your new proposed changes. Thanks.

Similarly, in s1, para 1, s/connections/communications/.

[Qin]: Okay.

In next to last para of s1:
OLD:
  Note that the Connection-Oriented OAM YANG DATA model is defined in
  [I-D.ietf-lime-yang-connection-oriented-oam-model].

NEW:
  Note that the YANG DATA model for OAM protcols using connection-oriented
  communications is defined in
  [I-D.ietf-lime-yang-connection-oriented-oam-model].
END

[Qin]: Accepted, thanks.

s2.1: The term 'Test point' needs some actual definition - It appears from the 
body of the document that a TP is effectively equated to an interface together 
with an associated stack layer (MAC, IP, etc) or superimposed application 
technology (VPN end point, etc.).  One query that came into my mind around this 
was what happens if the IP address associated with an interface is changed 
dynamically (e.g., when using IPv6 privacy addresses).  Can the YANG manager 
understand that it is still dealing with the same interface although the IP 
address has changed?  I wondered if the interfaces really needed some sort of 
identifier (e.g., interface number) that would tie all the pieces together as 
well as the intra-/inter-layer pointers.

[Qin]: I suspect interface number is local identifier, you can change your IP 
address of destination, that's why we can test whether the new address of 
destination is reachable. If IP address of source, we need to run another OAM 
diagnostic test. Here is the proposed definition for test point:
"
  Test point is a functional entity that is defined
  at a node in the network and can initiate and/or react to OAM
  diagnostic test.  This document focuses on the data-plane
  functionality of TPs, while TPs interact with the control plane and
  with the management plane as well.

"
s3.3:
  OAM
  neighboring test points are referred to a list of neighboring test
  points in the same layer that are related to the current test point.
  This allows users to easily navigate between related neighboring
  layers to efficiently troubleshoot a defect.  In this model, the
  'position' leaf defines the relative position of the neighboring test
  point corresponding to the current test point in the same layer, and
  is provided to a

Re: [Gen-art] Genart telechat review of draft-ietf-lime-yang-connectionless-oam-methods-09

[Carlos Pignataro (cpignata)]

Brian,

Thank you for your GenART review!

I will let the authors comment on and propose edits for the “units” minor issue 
and the nits. 

However, please find one comment inline.

> On Oct 14, 2017, at 12:39 AM, Brian Carpenter  
> wrote:
> 
> Reviewer: Brian Carpenter
> Review result: Ready with Issues
> 
> Gen-ART *Last Call* review of 
> draft-ietf-lime-yang-connectionless-oam-methods-09
> 
> 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-lime-yang-connectionless-oam-methods-09.txt
> Reviewer: Brian Carpenter
> Review Date: 2017-10-14
> IETF LC End Date: 2017-10-25
> IESG Telechat date: 2017-10-26
> 
> Summary: Ready with issues
> 
> 
> Comment:
> 
> 
> The shepherd says:
> 
>> This includes at least two different implementations of
>> the model, as well as product and demos at Bits-n-Bytes.
> 
> Shouldn't WGs make routine use of BCP 205, RFC 7942 "Improving
> Awareness of Running Code: The Implementation Status Section"?
> 

Yes!!!

Although a section in an Internet-Draft is not the most convenient way of 
tracking running code, it is better than none. At least, it self-contains spec 
and code status within a single document. As an editor I tend to add it as much 
as it makes sense.

As shepherd/chair for this document, unfortunately, at this stage it is too 
late for these document to play catch-up with another section, given that:

   Since this information is necessarily time dependent, it is
   inappropriate for inclusion in a published RFC.  The authors should
   include a note to the RFC Editor requesting that the section be
   removed before publication.

That said, I would strongly encourage you to discuss this topic and find ways 
to make more intentional in-the-workflow use of the “”Implementation Status”. 
This is a good comment but a wrong target.

Your comment starts with “Shouldn't WGs”, so this is a comment that ought to be 
directed to the Wg-chairs mailer, the IESG, early reviewers and Directoragtes, 
and other more relevant vehicles.

Thanks,

— Carlos.

> Minor Issues:
> -
> 
> In the following:
> 
> |  +--ro min-delay-value? uint32
> |  +--ro max-delay-value? uint32
> |  +--ro average-delay-value? uint32
> +--ro session-jitter-statistics
> |  +--ro time-resolution-value?   identityref
> |  +--ro min-jitter-value?uint32
> |  +--ro max-jitter-value?uint32
> |  +--ro average-jitter-value?uint32
> 
> what are the units for the delay-value and jitter-value
> elements, and what definition of 'jitter' is intended?
> 
> 
>  identity protocol-id-internet {
>base protocol-id;
>description
>  "Internet Protocols.";
>  }
> 
> It isn't clear what "Internet Protocols" means. It seems totally non-specific.
> 
> Nits:
> -
> 
>  identity protocol-id-propreitary {
>base protocol-id;
>description
>  "Propreitary protocol (eg.,IP SLA).";
> 
> s/propreitary/proprietary/
> s/Propreitary/Proprietary/
> 
> 

___
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-spring-lsp-ping-11

[Carlos Pignataro (cpignata)]

Thank you, Wassim!

—
Carlos Pignataro, car...@cisco.com<mailto:car...@cisco.com>

“Sometimes I use big words that I do not fully understand, to make myself sound 
more photosynthesis."

On Oct 9, 2017, at 2:10 PM, Wassim Haddad 
mailto:wassim.had...@ericsson.com>> 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:
https://trac.ietf.org/trac/gen/wiki/GenArtfaq


Document: draft-ietf-mpls-spring-lsp-ping-11
Reviewer:  Wassim Haddad
Review Date: 09 October 2017
IETF LC End Date: 06 October 2017
IESG Telechat Date: 12 October 2017

Summary:  This draft is ready for publication as proposed RFC

- Major Issues: None

- Minor Issues: None


Regards,

Wassim H.

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

Re: [Gen-art] Genart last call review of draft-ietf-sfc-nsh-19

[Carlos Pignataro (cpignata)]

Thanks to you, Dan!

—
Carlos Pignataro, car...@cisco.com<mailto:car...@cisco.com>

“Sometimes I use big words that I do not fully understand, to make myself sound 
more photosynthesis."

On Aug 31, 2017, at 11:56 PM, Dan Romascanu 
mailto:droma...@gmail.com>> wrote:

Hi Carlos,

Thank you for addressing my comments. Your suggested edits seem to address
the issues.

Regards,

Dan


On Fri, Sep 1, 2017 at 3:55 AM, Carlos Pignataro (cpignata) <
cpign...@cisco.com<mailto:cpign...@cisco.com>> wrote:

Hi, Dan,

Many thanks for your detailed and valuable review, and apologies for the
delay in Ack-ing and responding.

Please see inline.

—
Carlos Pignataro, car...@cisco.com<mailto:car...@cisco.com>

“Sometimes I use big words that I do not fully understand, to make myself
sound more photosynthesis."

On Aug 22, 2017, at 11:34 AM, Dan Romascanu 
mailto:droma...@gmail.com>> wrote:

Reviewer: Dan Romascanu
Review result: Almost 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

<https://trac.ietf.org/trac/gen/wiki/GenArtfaq>.

Document: draft-ietf-sfc-nsh-19
Reviewer: Dan Romascanu
Review Date: 2017-08-22
IETF LC End Date: 2017-08-25
IESG Telechat date: 2017-09-14

Summary:

This document describes the header (called Network Service Header - NSH)
to be
inserted in packets and frames in order to create packets and frames that
realize service functions described by other SFC documents. It needs to
be read
in conjunction with RFC 7665 and other documents as the SFC control
plane I-D
in order to make sense of the required functionality. This part of the
SFC
solution seems almost ready, but a few issues mentioned below need in my
opinion clarification before the document is approved.

Thank you for this summary — you raise good points.


Major issues:

1. Section 11.1 claims: 'An IEEE EtherType, 0x894F, has been allocated
for
NSH'. I could not find this value in the tables displayed by the IEEE
Registration Authority (RAC) - for example at
http://standards-oui.ieee.org/ethertype/eth.txt. Neither does IANA at
https://www.iana.org/assignments/ieee-802-numbers/ieee-802-numbers.xhtml
(which
would not be in any case the authoritative source). Can you please
indicate the
source that this is indeed a confirmed IEEE EtherType registration.

I am not sure how often that page is updated, but the same link you
include, http://standards-oui.ieee.org/ethertype/eth.txt, shows:

0x894F
894F: NSH (Network Service Header). Reference: draft-ietf-sfc-nsh-18

Granted, that registration will be updated with the RFC number instead of
the I-D, when it publishes.


2. Section 5 refers to ietf-rtgwg-dt-encap which is expired. If I
understand
correctly the status of this work, there is a design team in place in the
Routing Area created to look at common issues for the different data
plane
encapsulations being discussed in various WGs including SFC. This leaves
the
issue unsettled at this stage and this may be a problem for a standards
track
document. I suggest that first the reference to the expired document is
removed, second that the issue is marked as 'open' and subject for
future work.


Good suggestion. Instead of removing the reference all together, we can
mark it as exemplifying of one approach.

Minor issues:

1.  Two values 'Experiment 1' and 'Experiment 2' are defined in section
2.2 and
11.2.5 for the Next Protocol. This seems a little odd. Why 2? Why are
they
defined at the end of the range? Maybe there is an explanation for those
who
know the history but for an un-initiated reader or a future implementer
this
seems odd.

There is no strong rational behind the number of values (two) or the
location (towards the end of the range). There are two values as it seems
appropriate given the same of the number space (2 out of 256).

Perhaps, it’s somewhat following common practice started at
https://tools.ietf.org/html/rfc3692#section-2.1 (2 values for and 8-bit
field, closer to the end).


2. In Section 2.2 I see:

All other flag fields, marked U, are unassigned and available for
 future use, see Section 11.2.1.  Unassigned bits MUST be set to zero
 upon origination, and MUST be ignored and preserved unmodified by
 other NSH supporting elements.  Elements which do not understand the
 meaning of any of these bits MUST NOT modify their actions based on
 those unknown bits.

The way the last sentence is written it seems to open the path for
elements
that claim to 'understand' the meaning of some Unassigned bit to modify
its
behavior based upon it. This does not seem good, as at transmission all
Unassigned bits MUST be set to zero. I would suggest to make the
statement
simpler and just say that at reception a

Re: [Gen-art] Genart last call review of draft-ietf-sfc-nsh-19

[Carlos Pignataro (cpignata)]

Hi, Dan,

Many thanks for your detailed and valuable review, and apologies for the delay 
in Ack-ing and responding.

Please see inline.

—
Carlos Pignataro, car...@cisco.com

“Sometimes I use big words that I do not fully understand, to make myself sound 
more photosynthesis."

> On Aug 22, 2017, at 11:34 AM, Dan Romascanu  wrote:
> 
> Reviewer: Dan Romascanu
> Review result: Almost 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
> 
> <https://trac.ietf.org/trac/gen/wiki/GenArtfaq>.
> 
> Document: draft-ietf-sfc-nsh-19
> Reviewer: Dan Romascanu
> Review Date: 2017-08-22
> IETF LC End Date: 2017-08-25
> IESG Telechat date: 2017-09-14
> 
> Summary:
> 
> This document describes the header (called Network Service Header - NSH) to be
> inserted in packets and frames in order to create packets and frames that
> realize service functions described by other SFC documents. It needs to be 
> read
> in conjunction with RFC 7665 and other documents as the SFC control plane I-D
> in order to make sense of the required functionality. This part of the SFC
> solution seems almost ready, but a few issues mentioned below need in my
> opinion clarification before the document is approved.

Thank you for this summary — you raise good points.

> 
> Major issues:
> 
> 1. Section 11.1 claims: 'An IEEE EtherType, 0x894F, has been allocated for
> NSH'. I could not find this value in the tables displayed by the IEEE
> Registration Authority (RAC) - for example at
> http://standards-oui.ieee.org/ethertype/eth.txt. Neither does IANA at
> https://www.iana.org/assignments/ieee-802-numbers/ieee-802-numbers.xhtml 
> (which
> would not be in any case the authoritative source). Can you please indicate 
> the
> source that this is indeed a confirmed IEEE EtherType registration.

I am not sure how often that page is updated, but the same link you include, 
http://standards-oui.ieee.org/ethertype/eth.txt, shows:

0x894F
894F: NSH (Network Service Header). Reference: draft-ietf-sfc-nsh-18

Granted, that registration will be updated with the RFC number instead of the 
I-D, when it publishes.

> 
> 2. Section 5 refers to ietf-rtgwg-dt-encap which is expired. If I understand
> correctly the status of this work, there is a design team in place in the
> Routing Area created to look at common issues for the different data plane
> encapsulations being discussed in various WGs including SFC. This leaves the
> issue unsettled at this stage and this may be a problem for a standards track
> document. I suggest that first the reference to the expired document is
> removed, second that the issue is marked as 'open' and subject for future 
> work.
> 

Good suggestion. Instead of removing the reference all together, we can mark it 
as exemplifying of one approach.

> Minor issues:
> 
> 1.  Two values 'Experiment 1' and 'Experiment 2' are defined in section 2.2 
> and
> 11.2.5 for the Next Protocol. This seems a little odd. Why 2? Why are they
> defined at the end of the range? Maybe there is an explanation for those who
> know the history but for an un-initiated reader or a future implementer this
> seems odd.

There is no strong rational behind the number of values (two) or the location 
(towards the end of the range). There are two values as it seems appropriate 
given the same of the number space (2 out of 256).

Perhaps, it’s somewhat following common practice started at 
https://tools.ietf.org/html/rfc3692#section-2.1 (2 values for and 8-bit field, 
closer to the end).

> 
> 2. In Section 2.2 I see:
> 
>> All other flag fields, marked U, are unassigned and available for
>   future use, see Section 11.2.1.  Unassigned bits MUST be set to zero
>   upon origination, and MUST be ignored and preserved unmodified by
>   other NSH supporting elements.  Elements which do not understand the
>   meaning of any of these bits MUST NOT modify their actions based on
>   those unknown bits.
> 
> The way the last sentence is written it seems to open the path for elements
> that claim to 'understand' the meaning of some Unassigned bit to modify its
> behavior based upon it. This does not seem good, as at transmission all
> Unassigned bits MUST be set to zero. I would suggest to make the statement
> simpler and just say that at reception all elements MUST NOT modify their
> actions based on these bits.
> 

Very good point, and good improvement. Applied.

> 3. In Section 2.2 I see:
> 
>> 0xF - This value is reserved 

Re: [Gen-art] Genart last call review of draft-ietf-spring-oam-usecase-06

[Carlos Pignataro (cpignata)]

 it.

As I said, I am happy with either status and can see arguments both ways. I 
would not object to a change. 

However, personally, I do not see the need.

> 
> Minor issues:
> 
> None.
> 
> Nits/editorial comments:
> 
> This document refers to RFC 4379, which has been obsoleted by RFC 8029. It
> seems like the references should be updated.
> 
> 

Indeed. Done in -07 and -08.

Thanks again, Pete!

—
Carlos Pignataro, car...@cisco.com

“Sometimes I use big words that I do not fully understand, to make myself sound 
more photosynthesis."

___
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-l2tpext-keyed-ipv6-tunnel-07

[Carlos Pignataro (cpignata)]

Thanks for the review, Paul!

Authors,

Please find some comments inline.

Carlos, as shepherd.

> On Oct 31, 2016, at 10:20 PM, 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-l2tpext-keyed-ipv6-tunnel-07
> Reviewer: Paul Kyzivat
> Review Date: 2016-10-26
> IETF LC End Date: 2016-10-28
> IESG Telechat date: 2016-11-03
> 
> Summary:
> 
> This draft is on the right track but has open issues, described in the review.
> 
> (Note: The draft is unchanged since Last Call, as is this review.)
> 
> Issues:
> 
> Major: 0
> Minor: 3
> Nits:  0
> 
> (1) MINOR: General comment
> 
> As best I can understand, this draft provides a new alternative approach 
> tunneling Ethernet over IPv6, that differs from L2TPv3 over IP in two key 
> ways:
> 
> - it uniquely associates a tunnel with an IPv6 address, simplifying routing 
> of arriving packets
> 
> - it does not use the L2TPv3 control plane, instead relying upon coordinated 
> consistent configuration of the two ends of the tunnel.
> 
> As best I can tell, these two choices are independent of one another.
> 
> IMO this draft would be improved with a substantial discussion of why this 
> new approach to tunneling, using these two features, is being offered as an 
> alternative. This is mentioned very slightly in Section 1, but seems 
> incomplete. What are the cons as well as the pros, and under what 
> circumstances will the pros outweigh the cons?
> 

I agree with this. Some text explaining when you would prefer this approach, 
and when not, would help.

> (2) MINOR: Section 3:
> 
> There is no explanation of why 64-bit cookies are chosen and required. Is 
> this because there is no mechanism for negotiation, so a fixed size is needed 
> to define the packet format? Since coordinated configuration of the two ends 
> is required wouldn't it be possible to allow the consistent configuration of 
> the cookie size? Better explanation would be helpful.
> 

This is related to Mirja’s comment as well, and some clarity will improve the 
doc.

> (3) MINOR: Section 5:
> 
> The 2nd paragraph uses "recommended" (non-normative) while the subsequent 
> paragraphs used "RECOMMENDED" (normative). Is this intentional?

Thanks,

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

Re: [Gen-art] Post-Telechat update (was Re: Gen-art LC review of draft-ietf-mpls-rfc4379bis-07)

[Carlos Pignataro (cpignata)]

Hi Elwyn,

Thanks! Please see inline.

Hi Jari, Deborah,

All major, minor, and nits/editorials (including these extra additional points) 
are now addressed.

On Oct 28, 2016, at 6:29 PM, Elwyn Davies 
mailto:elw...@dial.pipex.com>> wrote:

Hi Carlos,

:-)
Thanks for addressing the comments.  I have looked through -08 and there are a 
couple of extra points that I noticed - the s3.4 issue was effectively 
mentioned wrt s4.5 in my previous notes.


Anytime!

We addressed the major and the two minor issues, as that was the priority and 
what Jari recorded in the datatracker. We also did address the very vast 
majority of nits and editorials (a couple escaped), including some additional 
ones I found in editing.

Generally things are in good shape but there are some items that haven't been 
addressed or there is a quibble.


All addressed now — though “addressing” resulted in a no-change disposition in 
a couple instances.

Quibble fixed! :-)

If there is another version over the weekend I'll do my very best to check it 
before Monday.


I submitted a new revision -09, but *please* do not waste your precious weekend 
time on this. All issues are addressed, but if there is something we missed, it 
is within the mini-nit category. I don’t believe there’s any (naturally) but if 
there were, it can be addressed by the RFC Editor.

Enjoy your weekend!

More inline.

Regards,
Elwyn

Extra Points:
===

I Forgot to mention that there is lack of consistency in capitalisation of the 
message names: Personally I would go with Echo Request and Echo Reply 
throughout to make it clear that these are message names.


We’ll leave this capitalization one for the RFC Editor.

s3,4, para 1:

If the
   replying router is the destination (Label Edge Router) of the FEC,
   then a Downstream Detailed Mapping TLV SHOULD NOT be included in the
   MPLS echo reply.  Otherwise, the replying router SHOULD include a
   Downstream Detailed Mapping object for each interface over which this
   FEC could be forwarded.

I suspect that the SHOULD NOT ought to be MUST NOT.  Otherwise it needs an 
explanation of the circumstances in which the DDMAP TLV could be included.  
Similarly, the SHOULD needs to explain in what circumstances you wouldn't 
include one or more DDMAP TLVs.

If you ask me, personally, I’d say: use MUST / MUST NOT as sparingly as 
possible, only when interop is affected. Additionally, not every SHOULD / 
SHOULD NOT needs to explain the exceptional case.

It is perfectly OK to say that the SHOULD (NOT) is to cover for unforeseen 
circumstances, for future ideas, etc.

Consequently, no change regarding this.


s6.2.3: The Unassigned row should have a blank reference.


No. Because “Unassigned” comes with an Assignment criteria which is given in 
this document. Left as-is, as with all other Unassigned.

On 28/10/2016 02:29, Carlos Pignataro (cpignata) wrote:
Deal Elwyn,

Many thanks for a great review!

I just finished addressing all your comments: the major issue (easy to address, 
editorial fix, but with important implications), the minors, and all the nits. 
Surprisingly, I found a few small additional editorials, which I fixed as well.

Rev -08 would address all outstanding issues, from this review, Mirja, and a 
couple others.

Please see inline for a line-by-line set of responses.

On Oct 20, 2016, at 4:42 PM, Elwyn Davies 
mailto:elw...@dial.pipex.com>> 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><http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.

Document: draft-ietf-mpls-rfc4379bis-07.txt
Reviewer: Elwyn Davies
Review Date: 2016/10/21
IETF LC End Date: 2016/10/18
IESG Telechat date: (if known) -

Summary: Not ready.  There is one major issue (already notified to authors and 
agreed as an issue) and a considerable number of minor and editorial issues. I 
have worked through the various RFCs and errata that are subsumed into the new 
version and almost everything has been correctly translated AFAICS.  A couple 
of minor points are covered in the comments.

Major issues:

s3.4: A number of items that are used in the normative Downstream Detailed 
Mapping TLV were originally defined in s3.3 (Downstream Mapping TLV format) but 
have been shifted to Appendix A.2.  This appendix is marked as non-normative.  
Thus there are now no normative definitions for the various TLVs used in s3.4 
that are defined in A.2.  I fear that these need to be returned to the 
normative part of the specification.


This is an excellent catch. Thank you. The fix is simple and purely editorial 
but the implication is clear.

I finished addressing this, which you will see posted as the n

Re: [Gen-art] Gen-art LC review of draft-ietf-mpls-rfc4379bis-07

[Carlos Pignataro (cpignata)]

Deal Elwyn,

Many thanks for a great review!

I just finished addressing all your comments: the major issue (easy to address, 
editorial fix, but with important implications), the minors, and all the nits. 
Surprisingly, I found a few small additional editorials, which I fixed as well.

Rev -08 would address all outstanding issues, from this review, Mirja, and a 
couple others.

Please see inline for a line-by-line set of responses.

On Oct 20, 2016, at 4:42 PM, Elwyn Davies 
mailto:elw...@dial.pipex.com>> 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-mpls-rfc4379bis-07.txt
Reviewer: Elwyn Davies
Review Date: 2016/10/21
IETF LC End Date: 2016/10/18
IESG Telechat date: (if known) -

Summary: Not ready.  There is one major issue (already notified to authors and 
agreed as an issue) and a considerable number of minor and editorial issues. I 
have worked through the various RFCs and errata that are subsumed into the new 
version and almost everything has been correctly translated AFAICS.  A couple 
of minor points are covered in the comments.

Major issues:

s3.4: A number of items that are used in the normative Downstream Detailed 
Mapping TLV were originally defined in s3.3 (Downstream Mapping TLV format) but 
have been shifted to Appendix A.2.  This appendix is marked as non-normative.  
Thus there are now no normative definitions for the various TLVs used in s3.4 
that are defined in A.2.  I fear that these need to be returned to the 
normative part of the specification.


This is an excellent catch. Thank you. The fix is simple and purely editorial 
but the implication is clear.

I finished addressing this, which you will see posted as the new revision. I am 
super happy with the outcome.

[I think it would be simplest and least error prone to swap the text that was 
in s3.3 of RFC 4379 back out of A.2 and put backward references to the new s3.4 
into A.2 as necessary.]

Minor issues:

Sender/receiver terminology: The document can be somewhat confusing to a naive 
reader.  Sender and receiver are used in multiple contexts.  Where the context 
appears to relate to LSP ping, both senders and receivers are involved in 
sending LSP ping packets.  In general, sender and receiver appear to imply 
sending and receiving of Echo Request messages with their roles reversed with 
respect to Echo Responses, with the receiver stimulated to send an Echo 
Response by receiving an Echo Request.  It would help if this terminology and 
usage was explicitly set out early in the document.  Additionally, some 
instances would be made more comprehensible by making the function explicit in 
the text e.g., in the operation of return codes.

Re-reading after fixing all the nits below, which include some sender 
clarifications, looks good.


s1.4/s3/s6.2.3: The R (Global) flag is defined in RFC 6426.  Unfortunately it 
isn't in the IANA considerations there as was spotted in RFC Erratum 4012.  
Might be worth mentioning the erratum (probably in s1.4?)  Alternatively this 
document can be made to provide the IANA specification for the R flag and the 
erratum closed.

The WG decided to keep the definition of the R Flag in RFC 6426 and not here — 
consequently, there’s little that can really be done as the erratum (which 
really is symbolic since the IANA registry is fixed) applies to RFC 6426 and 
not to RFC 4379.


s2.1/s6: An update to 
http://www.iana.org/assignments/iana-ipv4-special-registry/iana-ipv4-special-registry.xhtml
 is needed to replace RFC 4379 with RFC-to-be for special exceptions to usage 
rules.


Done.

s3.5, Clandestine Channel via Pad TLV:  As specified the value part of a Pad 
TLV can serve as a clandestine channel since the  value field contents are 
ignored.


Added the following to S5:
   The value part of the Pad TLV contains a variable number of octets.
   With the exception of the first octet, these contents, if any, are
   ignored on receipt, and can therefore serve as a clandestine channel.


s3.5, Usefulness of Pad TLV:  Could you explain circumstances in which a Pad 
TLV would be needed please. I can't see any at present.


Sure — when you want to send pings of various sizes for troubleshooting. I’ve 
used it in productions :-)

Nits/editorial comments:
==

Thank for for these. Unless I make a specific follow-up inline, the nit is 
fixed.

General: s/i.e. /i.e., / (two instances  s3.2, last para; s4.5.1, para 3)

s1, para 1: s/methods of reliable reply/methods of providing reliable reply/

s1.4, bullet 4: Need to expand acronym PW on first use.

s1.4, bullet 4: need to move expansion of

Re: [Gen-art] Gen-ART Telechat review of draft-ietf-mpls-entropy-lsp-ping-04

[Carlos Pignataro (cpignata)]

Dear Peter,

Many thanks for taking the time to go through the document with an editorial 
fine-tooth comb.

Although your summary, labeled [Ready with nits], says:
> I really have no problems with the documents other than some mostly
> inconsequential nits.

I took the time to fix every single one of the small nits you identified. 
That’s the least we could do, out of respect of you taking the time and helping 
the document improve.

Our working copy incorporates fixes to all these nits. Thank you.

I must share with you that the real value of your thorough review is in the 
Major and Minor categories, and that General-Area technical review — not in the 
editorial nit identification. It was excruciatingly hard to identify some of 
these nits, given that you use “Page x, Section y.z, n-th bullet point, m-th 
sentence” locators, which are not present in the (submitted) XML source. I 
expect the RFC Editor might find a couple more, as part of the copy edit, at 
that final stage before publication when it makes more sense.

Thanks again,

— Carlos.



> On Aug 29, 2016, at 11:26 PM, Peter Yee  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 background on Gen-ART,
> please see the FAQ at
> 
> 
> Document: draft-ietf-mpls-entropy-lsp-ping-04
> Reviewer: Peter Yee
> Review Date: August 26, 2016
> IETF LC End Date: August 26, 2016
> IESG Telechat date: September 1, 2016
> 
> Summary: This draft is basically ready for publication as a Proposed
> Standard, but has some nits that should be fixed before publication. [Ready
> with nits]
> 
> This draft expands the ability to perform MPLS LSP Ping and Traceroute
> operations in the presence of Entropy Labels when LSRs use disparate load
> balancing methods.
> 
> I really have no problems with the documents other than some mostly
> inconsequential nits.
> 
> The items below are the same as given in the LC review.
> 
> Major issues: None
> 
> Minor issues: None
> 
> Nits:
> 
> General:
> 
> Page 3, Section 1.1: delete the periods after each definition.
> 
> Change "ELI/EL pushing" to "ELI/EL-pushing".
> 
> Specific:
> 
> Page 1, Abstract, 1st paragraph, 3rd sentence: expand LSRs here as this is
> the first use of the term.  Put LSRs in parenthesis.
> 
> Page 1, Abstract, 1st paragraph, 4th and 5th sentences: change "non-EL
> based" to "non-EL-based".
> 
> Page 3, FEC definition: change "Equivalent" to "Equivalence".
> 
> Page 4, Section 1.2 , 2nd paragraph, last sentence: append a comma after
> "e.g.".
> 
> Page 4, Section 1.2, 3rd paragraph, second sentence: change "to not be"  to
> "not being".
> 
> Page 4, Section 1.2, 1st bullet point, 1st sentence: insert "the" before
> "label".
> 
> Page 5, Section 2, 2nd paragraph, 2nd sentence: append a comma after "y".
> 
> Page 5, Section 2, 3rd paragraph, 5th sentence: change "(outgoing
> interface)" to "(outgoing) interface".
> 
> Page 6, 1st sentence: insert "The" before "Current" after making it lower
> case.  Insert "the" before "following".
> 
> Page 6, 3rd bullet point, 1st sentence: delete the comma after "ECMP".
> 
> Page 6, 4th bullet item, 1st sentence: delete the comma after "ECMP".
> Insert "the" before "associated".
> 
> Page 6, 3rd asterisk bullet item: change "based on EL" to "based on the EL".
> 
> Page 6, 4th asterisk bullet item: insert "an" before "ELI".
> 
> Page 7, Section 3, 1st paragraph, 1st sentence: change the space between
> "label" and "based" to a hyphen.
> 
> Page 7, Section 4, 2nd paragraph, 1st sentence: change "PW-FEC" to "PW FEC".
> 
> Page 9, Section 6, 1st paragraph, 2nd sentence: append a comma after "one".
> 
> Page 9, L flag definition, 2nd sentence: insert "to one" before "in the echo
> reply".  Or consider working with the definition of "set" to mean "using a
> value of one" and "clear" to mean using a value of "zero" as you have done
> in other parts of the document.
> 
> Page 9, E flag definition, 2nd sentence: insert "to one" before "in the echo
> reply".
> 
> Page 11, Associated Label Multipath Information definition, 1st asterisk
> bullet item: change "16 bit" to "16-bit".
> 
> Page 12, 1st and 2nd asterisk bullet points: there is no previous mention of
> an "IP Associated Label Multipath Information".  You probably want to drop
> "IP" to match Figure 2.  Whatever you decide, make the change consistently
> throughout the document as there are other instances of "IP Associated Label
> Multipath Information", some in mixed case.  This is the only nit of real
> consequence.
> 
> Page 12, 3rd bullet item: insert "an" before "echo".  Insert "the" before
> "DS".
> 
> Page 13, Section 9, 1st paragraph after numbered items, 1st sentence: change
> "to not" to "not to".  (That just seems to read m

Re: [Gen-art] Late comment on draft-ietf-bfd-seamless-ip-04

[Carlos Pignataro (cpignata)]

Hi, Elwyn,

Thanks for the re-review of a different document :-) All comments welcome and 
help, thanks.

> On May 4, 2016, at 4:43 AM, Elwyn Davies  wrote:
> 
> Hi.
> 
> While reviewing draft-ietf-l2tpext-sbfd-discriminator-05 for gen-art, I came 
> across a
> 'common mode' issue with multiple discriminators that lead me to check the 
> various other seamless BFD drafts.
> 
> In the process I noticed the last paragraph in Section 5.1.1 of 
> draft-ietf-bfd-seamless-ip-04 contained the following text:
>>This also requires S-BFD control packets not be dropped by the
>>responder node due to TTL expiry.  Thus implementations on the
>>responder MUST allow received S-BFD control packets taking TTL expiry
>>exception path to reach corresponding reflector BFD session.
> This struck me as out of line with (AFAICS) every existing IP implementation. 
> TTL expiry checking is typically deep in the stack and making an exception 
> for this one case is (IMO) likely to be problematic. It may even be a 
> security issue. Have I misunderstood what is going on here?
> 

See first para of https://tools.ietf.org/html/rfc4379#section-4.4 
, as one example, of this OAM 
practice.

Thanks,

— Carlos.

> Regards,
> Elwyn



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] Geb-ART Telechat review of draft-ietf-bfd-seamless-ip-04

[Carlos Pignataro (cpignata)]

Hi, Dan,

Thanks for following up.

Alvaro, as responsible AD, responded as you can see here: 
https://www.ietf.org/mail-archive/web/gen-art/current/msg13149.html 


Thanks,

— Carlos.

> On May 4, 2016, at 6:46 AM, Romascanu, Dan (Dan)  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-bfd-seamless-ip-04
> Reviewer: Dan Romascanu
> Review Date: 2016/5/4
> IETF LC End Date: 2016/4/12
> IESG Telechat date: 2016/5/5
> 
> Summary: Ready with one issue
> 
> The document is well written and complete, but requires a good understanding 
> of BFD (RFC 5880, RFC 5881) and of the use-cases 
> (draft-ietf-bfd-seamless-use-case) document.
> 
> In my initial review I raised two issues. One was accepted and an editorial 
> change was made in draft-04. The second one was:
> 
> -  This document extends the usage of port 3785 adding the function 
> of being the destination port for the S-BFD echo packets. Should not this be 
> regarded as an update of RFC 5881 and mentioned as such on the front page?
> 
> The authors answered the following:
> 
> -  I do not have a strong opinion one way or another — I will leave 
> this one to the AD’s guidance, and I am happy to mark this document as 
> updating RFC 5881 if that’s the preferred direction
> 
> No change was made. I would like to make sure that the responsible AD has 
> seen this comment. It’s not a show-stopper, but I still believe that marking 
> this document as an update to RFC 5881 is better.
> 
> Major issues:
> 
> Minor issues:
> 
> Nits/editorial comments:



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-bfd-seamless-base-09

[Carlos Pignataro (cpignata)]

Thank you for your follow-up note, Dan!

— Carlos.

> On May 4, 2016, at 6:30 AM, Romascanu, Dan (Dan)  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-bfd-seamless-base-09
> Reviewer: Dan Romascanu
> Review Date: 2016/3/29
> IETF LC End Date: 2016/4/12
> IESG Telechat date: 2016/5/5
> 
> Summary: Ready
> 
> The document is well written and complete, but requires a good understanding 
> of BFD (RFC 5880) and of the use-cases (draft-ietf-bfd-seamless-use-case) 
> document. I raised three (no show-stopper) issues in my first review. Two of 
> them let to clarification and editorial improvements in the text. The third 
> one was clarified in the mail exchange with the authors and I agree that no 
> change is acceptable.
> 
> Major issues:
> 
> Minor issues:
> 
> Nits/editorial comments:
> 
> 1.



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-ospf-sbfd-discriminator-04

[Carlos Pignataro (cpignata)]

Hi, Pete,

Many thanks for your review.

Good catches, I agree with the three editorial suggestions below. I’ve made 
these changes in our working copy.

Thanks,

— Carlos.

> On Apr 18, 2016, at 12:09 PM, Pete Resnick  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-ospf-sbfd-discriminator-04
> Reviewer: Pete Resnick
> Review Date: 2016-04-18
> IETF LC End Date: 2016-04-26
> IESG Telechat date: 2016-05-05
> 
> Summary: This draft is ready for publication as a Proposed Standard RFC.
> 
> Major issues: None
> 
> Minor issues: None
> 
> Nits/editorial comments: Two clarifications, one typo:
> 
> 2.1:
> 
> OLD
> Type - S-BFD Discriminator TLV Type
> NEW
> Type - S-BFD Discriminator TLV Type (TBD [to be filled in by IANA])
> END
> 
> OLD
> Length - Total length of the discriminator (Value field) in octets,
> not including the optional padding. The Length is a multiple of 4
> octets, and consequently specifies how many Discriminators are
> included in the TLV.
> NEW
> Length - Total length of the discriminator(s) that appear in the
> Value field, in octets. Each discriminator is 4 octets, so the Length
> is 4 times the number of Discriminators included in the TLV. There is
> no optional padding for this field.
> END
> 
> 2.2:
> 
> OLD
> Note that the S-BFD session may be required to pan multiple areas
> NEW
> Note that the S-BFD session may be required to span multiple areas
> END
> 
> --
> Pete Resnick http://www.qualcomm.com/~presnick/ 
> 
> Qualcomm Technologies, Inc. - +1 (858)651-4478
> 



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-l2tpext-sbfd-discriminator-03

[Carlos Pignataro (cpignata)]

Hi, Elwyn,

Many thanks again. I am more than happy to accommodate these editorials and 
further improve the doc.

Expanded acronyms (in addition to L2TPv3, there was one “BFD” missing, as well 
as the Title and abbrev). I updated the ‘out of scope’ text, but, finally, I 
did not modify the Abstract — while I understand RFC numbers in a non-citation 
fashion are OK (although semantically they play as a citation), I’d prioritize 
consistency with the other S-BFD documents (OSPF, ISIS).

Just posted a new rev:
URL:
https://www.ietf.org/internet-drafts/draft-ietf-l2tpext-sbfd-discriminator-04.txt
Status: 
https://datatracker.ietf.org/doc/draft-ietf-l2tpext-sbfd-discriminator/
Htmlized:   
https://tools.ietf.org/html/draft-ietf-l2tpext-sbfd-discriminator-04
Diff:   
https://www.ietf.org/rfcdiff?url2=draft-ietf-l2tpext-sbfd-discriminator-04

Enjoy your weekend,

— Carlos.

From: Elwyn Davies mailto:elw...@dial.pipex.com>>
Date: Friday, April 15, 2016 at 12:30 PM
To: Carlos Pignataro mailto:cpign...@cisco.com>>
Cc: General area reviewing team mailto:gen-art@ietf.org>>, 
"draft-ietf-l2tpext-sbfd-discriminator@ietf.org<mailto:draft-ietf-l2tpext-sbfd-discriminator@ietf.org>"
 
mailto:draft-ietf-l2tpext-sbfd-discriminator@ietf.org>>
Subject: Re: Gen-art LC review of draft-ietf-l2tpext-sbfd-discriminator-03

Hi, Carlos.

Thanks for the response.

First: a remaining acronym: L2TPv3 needs to be expanded on first use in the 
Abstract.

Second: Although citations are not allowed in the Abstract, this doesn't 
prevent explicit RFC numbers in a non-citation form.  So, yes, 
[RFC5880][I-D.draft-ietf-bfd-seamless-base] is not allowed but '(RFC 5880, RFC 
)' is fine

Finally:
I took a quick look around the various other S-SFD in 'xxx' drafts, of which 
the IS-IS is already in the RFC Editor queue and see that the 'out of scope' 
words for the multiple discriminator case appears to be the selected way 
forwards - so the sentence you added is good.

I am afraid I still can't make much sense of the sentence after it:

When multiple S-BFD discriminators are
  advertised, the mechanism to choose a subset of specific
  discriminator(s) is out of scope for this document.

Something being chosen is a mechanism and this is out of scope...

The form used in the IS-IS draft:

When multiple S-BFD discriminators are
   advertised how a given discriminator is mapped to a specific use case
   is out of scope for this document.

seems clearer to me.

Cheers,
Elwyn

On 13/04/2016 20:35, Carlos Pignataro (cpignata) wrote:

Elwyn,

This is a great review. Thank you.

Please see inline.

Deborah,

We will be queueing edits, let me know when you’d want us to post an updated 
revision.



On Apr 10, 2016, at 1:26 PM, Elwyn Davies 
<mailto:elw...@dial.pipex.com> 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.

Apologies for the slightly late review - I was stricken by a stomach bug.



I hope you are feeling better!



For more information, please see the FAQ at

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

Document: draft-ietf-l2tpext-sbfd-discriminator-03.txt
Reviewer: Elwyn Davies
Review Date: 2016/04/10
IETF LC End Date: 2016/04/05
IESG Telechat date: (if known) -

Summary: Almost ready. There are a number of acronyms that need expansion and I 
am unclear how an implementation of S-BFD getting its discriminators via L2TPv3 
would know what entities the advertised discriminators (whether one or many) 
should be associated with. This probably just needs a single sentence to sort 
it out, but I found the existing wording to be either inappropriate or just 
plain wrong.



These items, with the exception of the acronym expansion, have already been 
discussed. See below line-by-line responses to each of these potential issues, 
as well as a set of HTML diffs from the working copy, FYI.



Nearly Major Issue:
Question:
The format allows multiple discriminators to be sent in one message.  Looking 
at the S-BFD base draft (s3), it is implied that if a S-BFD module is dealing 
with multiple discriminators they would be associated with multiple different 
entities.  How would the receiver know what entity each of the discriminators 
was supposed to be associated with?  It seems to me that the receiver would 
want to know this but I may not have understood what is going on here.  I guess 
one way would be to use a part of the discriminator bit pattern but I don't 
know if this might make it more difficult to achieve uniqueness in a domain.  
Alternatively a purpose  provided field could be sent in addition to each 
discriminator, or different AVP 

Re: [Gen-art] Gen-art LC review of draft-ietf-l2tpext-sbfd-discriminator-03

[Carlos Pignataro (cpignata)]

Elwyn,

This is a great review. Thank you.

Please see inline.

Deborah,

We will be queueing edits, let me know when you’d want us to post an updated 
revision.

> On Apr 10, 2016, at 1:26 PM, Elwyn Davies  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.
> 
> Apologies for the slightly late review - I was stricken by a stomach bug.
> 

I hope you are feeling better!

> For more information, please see the FAQ at
> 
> .
> 
> Document: draft-ietf-l2tpext-sbfd-discriminator-03.txt
> Reviewer: Elwyn Davies
> Review Date: 2016/04/10
> IETF LC End Date: 2016/04/05
> IESG Telechat date: (if known) -
> 
> Summary: Almost ready. There are a number of acronyms that need expansion and 
> I am unclear how an implementation of S-BFD getting its discriminators via 
> L2TPv3 would know what entities the advertised discriminators (whether one or 
> many) should be associated with. This probably just needs a single sentence 
> to sort it out, but I found the existing wording to be either inappropriate 
> or just plain wrong.
> 

These items, with the exception of the acronym expansion, have already been 
discussed. See below line-by-line responses to each of these potential issues, 
as well as a set of HTML diffs from the working copy, FYI.

> Nearly Major Issue:
> Question:
> The format allows multiple discriminators to be sent in one message.  Looking 
> at the S-BFD base draft (s3), it is implied that if a S-BFD module is dealing 
> with multiple discriminators they would be associated with multiple different 
> entities.  How would the receiver know what entity each of the discriminators 
> was supposed to be associated with?  It seems to me that the receiver would 
> want to know this but I may not have understood what is going on here.  I 
> guess one way would be to use a part of the discriminator bit pattern but I 
> don't know if this might make it more difficult to achieve uniqueness in a 
> domain.  Alternatively a purpose  provided field could be sent in addition to 
> each discriminator, or different AVP IDs used for well-known purposes.

Thanks for raising this — although this was discussed and addressed, it might 
not be self-evident. See the next comment.

> 
> The sentence at the end of para 4 of s2.1:
>> When multiple S-BFD discriminators are
>>   advertised, the mechanism to choose a subset of specific
>>   discriminator(s) is out of scope for this document.
> may be associated with this question but I am not sure

Indeed, this is the relevant paragraph.

This paragraph was also added to other related documents (ISIS, OSPF), and goes 
hand-in-hand with the following paragraph from draft-ietf-bfd-seamless-base-08:
   The use of multiple S-BFD
   discriminators by a single network node is therefore discouraged
   until a means of learning the mapping is defined.

Now, that said, it is clear that if it created confusion in this review, this 
can also create future confusion.

> (1) which end is supposed to be choosing - is the Initiator choosing which to 
> advertise or the Responder choosing which to 'do something with', and
> (2) it seems to me that the L2TPv3 receiver or its associated S-BFD module 
> would be deciding on some well-defined basis which entities were associated 
> with which designator rather than just making an arbitrary choice.
> 
> I suggest that a sentence indicating how the association of discriminators to 
> entities is done (or even that it needs to be done but how it is done is out 
> of scope) needs to be added, and the sentence above needs to be clarified or 
> subsumed in this new part (unless either of the more draconian alternatives 
> suggested above is thought to be appropriate).
> 

To really minimize the chance of that future confusion, I agree with your 
suggestion. I added such sentence and reworded the paragraph a bit. Further 
comments on the proposed text most welcome.

> Minor issues:
> None
> 
> Nits/editorial comments:
> Abstract:  I'm afraid you are going to have expand the acronyms AVP, L2TP and 
> BFD here.  References to RFC 5880 and the new S-BFD draft RFC would also be 
> helpful - in the form "(RFC 5880, I-D.ietf-bfd-seamless-base)”.

Acronyms expanded. Since the Abstract should not have citations, I am hesitant 
to add anything else. It is clearly in the Introduction.

> 
> s1.1: The  L2TP message names used in s2.1 and elsewhere (ICRQ, ICRP, OCRQ, 
> OCRP)  need to be expanded  - here would be as good as anywhere.
> 

S1.1 already specifies expectations to readers, which include these L2TP 
messages:

1.1.  Terminology

   The reader is expected to be very familiar with the terminology and
   protocol constructs defined in S-BFD (see Section 2 of
   [I-D.ietf-bfd-seamless-base]) and L2TPv3 (see Sect

Re: [Gen-art] Gen-ART Review of draft-ietf-bfd-seamless-ip-03

[Carlos Pignataro (cpignata)]

> On Apr 11, 2016, at 2:36 PM, Alvaro Retana (aretana)  
> wrote:
> 
> On 4/11/16, 12:30 PM, "Jeffrey Haas"  wrote:
> 
> Hi!
> 
>> On Tue, Mar 29, 2016 at 02:54:06PM +, Carlos Pignataro (cpignata)
>> wrote:
>>> Dan,
>>> 
>>> Many thanks for this review!
>>> 
>>> You raise two good questions, here¹s my take:
>>> I do not have a strong opinion one way or another ‹ I will leave this
>>> one to the AD¹s guidance, and I am happy to mark this document as
>>> updating RFC 5881 if that¹s the preferred direction.
>>> Indeed ‹ fixed in our working copy.
>> 
>> I'm of mixed opinion to mark it as updating.  The bulk of the
>> functionality
>> is separate procedures from RFC 5881.  The only thing that is updated is
>> the
>> echo port, which 5881 leaves very much out of scope for what is carried on
>> that port.
>> 
>> I agree that it's worth leaving the final call to Álvaro.
> 
> I don't think this document needs to be marked as updating 5881 because it
> doesn't change the procedures from that RFC, it enhances/extends with
> optional functionality (I.e. What is specified here is not needed for 5881
> implementations to interoperate).
> 

Works for me — agreed.

Thanks,

— Carlos.

> Thanks!
> 
> Alvaro.
> 



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 of draft-ietf-pals-seamless-vccv-02.txt

[Carlos Pignataro (cpignata)]

[Correcting gem-art with gen-art in the email alias]

Many thanks for your review, Francis.

All editorials fixed in my working copy. I left “encased” in since that term is 
used in RFC 5885 and others, but of course will take guidance from the RFC 
Editor.

Thanks,

— Carlos.

> On Apr 5, 2016, at 3:26 PM, Francis Dupont  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-pals-seamless-vccv-02.txt
> Reviewer: Francis Dupont
> Review Date: 20160331
> IETF LC End Date: 20160405
> IESG Telechat date: unknown
> 
> Summary: Ready
> 
> Major issues: None
> 
> Minor issues: None
> 
> Nits/editorial comments:
> - in ToC page 2 and 2.1 page 4: capabilites -> Capabilities
> 
> - in ToC page 2 and 6 page 9: Acknowledgements -> Acknowledgments
> 
> - 2.2.2 page 5 (twice): signalling -> signaling
> 
> - in 2.3 page 6: I am not sure (*) the "encased" term is common English
> (*) but I am not a native English speaker too... I suggest to ask
> someone from Asia for instance. Or simply leave this to the RFC Editor?
> 
> Regards
> 
> francis.dup...@fdupont.fr



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-bfd-seamless-ip-03

[Carlos Pignataro (cpignata)]

Dan,

Many thanks for this review!

You raise two good questions, here’s my take:
I do not have a strong opinion one way or another — I will leave this one to 
the AD’s guidance, and I am happy to mark this document as updating RFC 5881 if 
that’s the preferred direction.
Indeed — fixed in our working copy.

Thanks again,

— Carlos.

> On Mar 29, 2016, at 7:40 AM, Romascanu, Dan (Dan)  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-bfd-seamless-ip-03
> Reviewer: Dan Romascanu
> Review Date: 2016/3/29
> IETF LC End Date: 2016/4/12
> IESG Telechat date: 2016/5/5
> 
> Summary: Ready with minor issues
> 
> The document is well written and complete, but requires a good understanding 
> of BFD (RFC 5880, RFC 5881) and of the use-cases 
> (draft-ietf-bfd-seamless-use-case) document. A few minor issues are listed 
> below, it would be good to address them, but none is a show-stopper.
> 
> Major issues:
> 
> Minor issues:
> 
> 1.   This document extends the usage of port 3785 adding the function of 
> being the destination port for the S-BFD echo packets. Should not this be 
> regarded as an update of RFC 5881 and mentioned as such on the front page?
> 2.   In the IANA considerations section – when this I-D is approved and 
> becomes an RFC, should not the Reference (REQUIRED) become this RFC – a more 
> stable reference that the draft-akiya-bfd-seamless-ip?
> 
> Nits/editorial comments:



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-bfd-seamless-base-08

[Carlos Pignataro (cpignata)]

Hi, Dan,

Many thanks for this review!

Although you label these as not-shot-stoppers, they are very useful. Here’s a 
follow-up:
You are correct, set-up states transitions are minimized or eliminated with 
S-BFD. However, it can be argued (and it was our initial thinking) that the 
state set-up is also part of the actual test. Therefore, the starting is the 
same for both, but it takes shorter for CC packets to flow though. 
Consequently, in that case, “and completing” is probably better. If you 
consider the state setup as not part of the test, then “and starting” can be 
slightly more precise, assuming the time actual CC packets are on the ether is 
the same. I think that “and completing” is safer, but can easily be persuaded 
to use “and starting” with some additional text explaining the actual gain. No 
change so far.
Yes. Will update. I am adding also an Informational pointer to 
draft-ietf-bfd-seamless-ip. Basically added: “IPv4, IPv6, or MPLS based 
[seamless-ip] and other options are possible and can be defined in future 
documents.”
Nit fixed in the working copy.

Thanks again, do let me know if you have a strong preference and rational 
regarding #1.

Thanks,

— Carlos.

> On Mar 29, 2016, at 7:26 AM, Romascanu, Dan (Dan)  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-bfd-seamless-base-08
> Reviewer: Dan Romascanu
> Review Date: 2016/3/29
> IETF LC End Date: 2016/4/12
> IESG Telechat date: 2016/5/5
> 
> Summary: Ready with minor issues
> 
> The document is well written and complete, but requires a good understanding 
> of BFD (RFC 5880) and of the use-cases (draft-ietf-bfd-seamless-use-case) 
> document. A few minor issues are listed below, it would be good to address 
> them, but none is a show-stopper.
> 
> Major issues:
> 
> Minor issues:
> 
> 1.   In the introduction I see the following:
> 
> Ø One key aspect of the mechanism described in this document eliminates
>the time between a network node wanting to perform a continuity test
>and completing the continuity test.
> 
> I am wondering if this is really what is intended. If I understand correctly, 
> S-BFD does not eliminate the continuity test but the set-up states 
> transitions before the continuity test starts. Would not that rather be ‘… 
> and starting the continuity test.’?
> 
> 2.   In the last paragraph of Section 5:
> 
> Ø  Note that incoming S-BFD control packets may be IPv4, IPv6 or MPLS
>based.
> 
> If these are the only three options I suggest that the text explicitly 
> specify this. If other options are possible or may be possible in the future 
> I suggest that the text also clarifies this
> 
> Nits/editorial comments:
> 
> 1.   Second paragraph in Section 3: s/allocated toby a remote 
> node/allocated to by a remote node/



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 Call review of draft-ietf-intarea-gre-ipv6-11

[Carlos Pignataro (cpignata)]

Thank you, Meral!

Thumb typed by Carlos Pignataro.
Excuze typofraphicak errows

On Aug 6, 2015, at 02:17, Meral Shirazipour 
mailto:meral.shirazip...@ericsson.com>> wrote:

I am the assigned Gen-ART reviewer for this draft. For background on Gen-ART, 
please see the FAQ at < 
http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.

Please wait for direction from your document shepherd or AD before posting a 
new version of the draft.

Document:draft-ietf-intarea-gre-ipv6-11
Reviewer: Meral Shirazipour
Review Date:2015-08-06
IETF LC End Date:2015-07-09
IESG Telechat date: 2015-08-06

Summary: This draft is ready to be published as Standards Track RFC.

Major issues:

Minor issues:

Nits/editorial comments:

Best Regards,
Meral
---
Meral Shirazipour
Ericsson
Research
www.ericsson.com<http://www.ericsson.com>
___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

Re: [Gen-art] Last Call review of draft-ietf-sfc-architecture-08

[Carlos Pignataro (cpignata)]

Thanks Jim! Updated in the working copy.

— Carlos.

> On May 22, 2015, at 9:57 AM, Jim Guichard (jguichar)  
> wrote:
> 
> Looks good except in section 6 there are couple typos:
> 
> "BUilding from the categorization of [RFC7498], we can largely divide
> security consdierations in four areas:²
> 
> 
> 1. Change BUilding to Building.
> 2. Change consdierations to considerations.
> 
> Jim
> 
> On 5/21/15, 11:50 PM, "Carlos Pignataro (cpignata)" 
> wrote:
> 
>> Tom,
>> 
>> All great comments ‹ thank you.
>> 
>> All incorporated into our working copy (diffs attached here FYI) ‹ we can
>> submit when Jim/Alia signal.
>> 
>> Thanks,
>> 
>> ‹ Carlos.
>> 
>> 
>> 
>> 
>>> On May 21, 2015, at 8:53 PM, Tom Taylor 
>>> wrote:
>>> 
>>> 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-sfc-architecture-08
>>> Reviewer: Tom Taylor
>>> Review Date:2015-05-17
>>> IETF LC End Date:   2015-05-25
>>> IESG Telechat date: 2015-05-28
>>> 
>>> Summary:
>>> 
>>> There is one IPR declaration, which was repeated for two predecessor
>>> documents but not for the current draft. The draft is basically ready to
>>> go with a very minor issue and a few nits.
>>> 
>>> Major issues:
>>> 
>>> Minor issues:
>>> 
>>> The Security Considerations section rightly mentions the need to avoid
>>> leaking SFC information. However, it does this under the heading of
>>> "Classification". Could I suggest that the first two sentences of the
>>> "Classification" bullet be separated out under the title "Boundaries"?
>>> 
>>> Nits/editorial comments:
>>> 
>>> Sec. 1.2, third bullet from the bottom: spell out SFF on first use, and
>>> give a forward reference to the next section, i.e.,
>>>  "...interconnect the Service Function Forwarders (SFFs, see next
>>>   section) ..."
>>> 
>>> Sec. 1.2, next bullet: according to the RFC Editor Style Guide
>>> abbreviations list, FIB and RIB are not well-known abbreviations, hence
>>> need to be spelled out.
>>> 
>>> Sec. 1.3, Service Function Forwarder, last line: spell out SFP? I know
>>> the definition is just a few lines down, so this is a maybe.
>>> 
>>> Alternative suggestion: introduce a Section 1.3.1 at the beginning of
>>> the section, as follows:
>>> 
>>> "1.3.1 Key Abbreviations
>>> 
>>>  The terms listed here are defined in Section 1.3.2.
>>> 
>>>  SF Service Function
>>>  SFCService Function Chain or Service Function Chaining
>>>  SFFService Function Forwarder
>>>  SFPService Function Path
>>>  RSPRendered Service Path"
>>> 
>>> Sec. 2.1, second para., third line from bottom: s/the the/the/
>>> 
>> 
> 



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] Last Call review of draft-ietf-sfc-architecture-08

[Carlos Pignataro (cpignata)]

Tom,

All great comments — thank you.

All incorporated into our working copy (diffs attached here FYI) — we can 
submit when Jim/Alia signal.

Thanks,

— Carlos.

Title: Diff: draft-ietf-sfc-architecture-08.txt - draft-ietf-sfc-architecture-09.txt
 
 
 
 
 
   
   draft-ietf-sfc-architecture-08.txt   draft-ietf-sfc-architecture-09.txt  
   
  Network Working GroupJ. Halpern, Ed. Network Working GroupJ. Halpern, Ed.
  Internet-Draft  Ericsson Internet-Draft  Ericsson
  Intended status: Informational C. Pignataro, Ed. Intended status: Informational C. Pignataro, Ed.
  
  Expires: November 12, 2015 Cisco Expires: November 22, 2015 Cisco
  May 11, 2015 May 21, 2015
   
Service Function Chaining (SFC) Architecture   Service Function Chaining (SFC) Architecture
  
   draft-ietf-sfc-architecture-08  draft-ietf-sfc-architecture-09
   
  Abstract Abstract
   
 This document describes an architecture for the specification,This document describes an architecture for the specification,
 creation, and ongoing maintenance of Service Function Chains (SFC) increation, and ongoing maintenance of Service Function Chains (SFC) in
 a network.  It includes architectural concepts, principles, anda network.  It includes architectural concepts, principles, and
 components used in the construction of composite services throughcomponents used in the construction of composite services through
 deployment of SFCs, with a focus on those to be standardized in thedeployment of SFCs, with a focus on those to be standardized in the
 IETF.  This document does not propose solutions, protocols, orIETF.  This document does not propose solutions, protocols, or
 extensions to existing protocols.extensions to existing protocols.
   
  skipping to change at page 1, line 37 skipping to change at page 1, line 37
 Internet-Drafts are working documents of the Internet EngineeringInternet-Drafts are working documents of the Internet Engineering
 Task Force (IETF).  Note that other groups may also distributeTask Force (IETF).  Note that other groups may also distribute
 working documents as Internet-Drafts.  The list of current Internet-working documents as Internet-Drafts.  The list of current Internet-
 Drafts is at http://datatracker.ietf.org/drafts/current/.Drafts is at http://datatracker.ietf.org/drafts/current/.
   
 Internet-Drafts are draft documents valid for a maximum of six monthsInternet-Drafts are draft documents valid for a maximum of six months
 and may be updated, replaced, or obsoleted by other documents at anyand may be updated, replaced, or obsoleted by other documents at any
 time.  It is inappropriate to use Internet-Drafts as referencetime.  It is inappropriate to use Internet-Drafts as reference
 material or to cite them other than as "work in progress."material or to cite them other than as "work in progress."
   
  
 This Internet-Draft will expire on November 12, 2015.This Internet-Draft will expire on November 22, 2015.
   
  Copyright Notice Copyright Notice
   
 Copyright (c) 2015 IETF Trust and the persons identified as theCopyright (c) 2015 IETF Trust and the persons identified as the
 document authors.  All rights reserved.document authors.  All rights reserved.
   
 This document is subject to BCP 78 and the IETF Trust's LegalThis document is subject to BCP 78 and the IETF Trust's Legal
 Provisions Relating to IETF DocumentsProvisions Relating to IETF Documents
 (http://trustee.ietf.org/license-info) in effect on the date of(http://trustee.ietf.org/license-info) in effect on the date of
 publication of this document.  Please review these documentspublication of this document.  Please review these documents
   
  skipping to change at page 4, line 29 skipping to change at page 4, line 29
of SFs that needs to be applied to deliver a given service is   of SFs that needs to be applied to deliver a given service is
specific to each administrative entity.   specific to each administrative entity.
   
 o  The chaining of SFs and the criteria to invoke them are specifico  The chaining of SFs and the criteria to invoke them are specific

Re: [Gen-art] Gen-ART Last Call review of draft-ietf-mpls-oam-ipv6-rao-02

[Carlos Pignataro (cpignata)]

Thank you.


> On Jan 26, 2015, at 5:05 PM, Brian E Carpenter  
> wrote:
> 
> Looks good to me, thanks.
> 
>   Brian
> 
> On 27/01/2015 09:36, Carlos Pignataro (cpignata) wrote:
>> Hi, Brian,
>> 
>> On Jan 25, 2015, at 4:47 PM, Brian E Carpenter 
>> mailto:brian.e.carpen...@gmail.com>> wrote:
>> 
>> Hi Carlos,
>> 
>> On 26/01/2015 08:49, Carlos Pignataro (cpignata) wrote:
>> Hi, Brian,
>> 
>> Thanks for your review! Please see inline.
>> 
>> On Jan 25, 2015, at 2:29 PM, Brian E Carpenter 
>> mailto:brian.e.carpen...@gmail.com>> wrote:
>> 
>> 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-mpls-oam-ipv6-rao-02.txt
>> Reviewer: Brian Carpenter
>> Review Date: 2015-01-26
>> IETF LC End Date: 2015-02-04
>> IESG Telechat date:
>> 
>> Summary: Almost ready
>> 
>> 
>> Minor issues:
>> -
>> 
>> 1. Hop-by-hop options, and therefore Router Alert, are well known to
>> cause a serious performance issue or are simply ignored by many
>> routers (as warned in http://tools.ietf.org/html/rfc7045#section-2.2).
>> A pointer to that warning would be appropriate.
>> 
>> 
>> I do not believe this concern is very applicable to the MPLS OAM RAO. The 
>> whole point of RAO in an MPLS LSP is to be intercept the packet and punt it 
>> to a slow path, and it is not injected back. The MPLS OAM Router Alert 
>> option is invisible to the MPLS Label-switched hops, and when the LSP 
>> finishes, it is only processed once.
>> 
>> I am also not sure I understand the suggested action behind this comment. 
>> Are you suggesting we add a pointer to that Section, or that exact paragraph 
>> to the Security Considerations?
>> 
>> Well, maybe what you could do is add a statement that this type of RAO
>> is not subject to the problem of being ignored, because the appropriate
>> router will process it (on the slow path) by design. The generic problem
>> is that HbH options might be ignored even if the designer assumes otherwise,
>> which is why we added the warning in RFC 7045, and you're saying that
>> problem doesn't apply here.
>> 
>> Sounds good — I added the following paragraph (and Informational reference). 
>> All, can you please review?
>> 
>>   IPv6 packets containing the MPLS OAM Router Alert Option are
>>   encapsulated with an MPLS Header and not expected to be inspected by
>>   every label switched hop within an MPLS LSP.  Consequently, this
>>   value of the Router Alert Option will be processed by the appropriate
>>   router and is not subject to the problem of being ignored as
>>   described in Section 2.2 of [RFC7045].
>> 
>> 
>> 
>> 2. I'm a bit surprised to realise that new definitions of Router Alert
>> options are not routinely notified to the 6MAN WG.
>> 
>> We had run this through 6MAN, both on list and presenting twice in IETF 
>> meetings.
>> 
>> I must have been asleep, sorry!
>> 
>> 
>> No worries, thanks for the review!
>> 
>> — Carlos.
>> 
>>  Brian
>> 
>> Thanks!
>> 
>> Carlos.
>> 
> 

___
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-mpls-oam-ipv6-rao-02

[Carlos Pignataro (cpignata)]

Hi, Brian,

On Jan 25, 2015, at 4:47 PM, Brian E Carpenter 
mailto:brian.e.carpen...@gmail.com>> wrote:

Hi Carlos,

On 26/01/2015 08:49, Carlos Pignataro (cpignata) wrote:
Hi, Brian,

Thanks for your review! Please see inline.

On Jan 25, 2015, at 2:29 PM, Brian E Carpenter 
mailto:brian.e.carpen...@gmail.com>> wrote:

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-mpls-oam-ipv6-rao-02.txt
Reviewer: Brian Carpenter
Review Date: 2015-01-26
IETF LC End Date: 2015-02-04
IESG Telechat date:

Summary: Almost ready


Minor issues:
-

1. Hop-by-hop options, and therefore Router Alert, are well known to
cause a serious performance issue or are simply ignored by many
routers (as warned in http://tools.ietf.org/html/rfc7045#section-2.2).
A pointer to that warning would be appropriate.


I do not believe this concern is very applicable to the MPLS OAM RAO. The whole 
point of RAO in an MPLS LSP is to be intercept the packet and punt it to a slow 
path, and it is not injected back. The MPLS OAM Router Alert option is 
invisible to the MPLS Label-switched hops, and when the LSP finishes, it is 
only processed once.

I am also not sure I understand the suggested action behind this comment. Are 
you suggesting we add a pointer to that Section, or that exact paragraph to the 
Security Considerations?

Well, maybe what you could do is add a statement that this type of RAO
is not subject to the problem of being ignored, because the appropriate
router will process it (on the slow path) by design. The generic problem
is that HbH options might be ignored even if the designer assumes otherwise,
which is why we added the warning in RFC 7045, and you're saying that
problem doesn't apply here.

Sounds good — I added the following paragraph (and Informational reference). 
All, can you please review?

   IPv6 packets containing the MPLS OAM Router Alert Option are
   encapsulated with an MPLS Header and not expected to be inspected by
   every label switched hop within an MPLS LSP.  Consequently, this
   value of the Router Alert Option will be processed by the appropriate
   router and is not subject to the problem of being ignored as
   described in Section 2.2 of [RFC7045].



2. I'm a bit surprised to realise that new definitions of Router Alert
options are not routinely notified to the 6MAN WG.

We had run this through 6MAN, both on list and presenting twice in IETF 
meetings.

I must have been asleep, sorry!


No worries, thanks for the review!

— Carlos.

  Brian

Thanks!

Carlos.

___
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-mpls-oam-ipv6-rao-02

[Carlos Pignataro (cpignata)]

Hi, Brian,

Thanks for your review! Please see inline.

> On Jan 25, 2015, at 2:29 PM, Brian E Carpenter  
> 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-mpls-oam-ipv6-rao-02.txt
> Reviewer: Brian Carpenter
> Review Date: 2015-01-26
> IETF LC End Date: 2015-02-04
> IESG Telechat date:
> 
> Summary: Almost ready
> 
> 
> Minor issues:
> -
> 
> 1. Hop-by-hop options, and therefore Router Alert, are well known to
> cause a serious performance issue or are simply ignored by many
> routers (as warned in http://tools.ietf.org/html/rfc7045#section-2.2).
> A pointer to that warning would be appropriate.


I do not believe this concern is very applicable to the MPLS OAM RAO. The whole 
point of RAO in an MPLS LSP is to be intercept the packet and punt it to a slow 
path, and it is not injected back. The MPLS OAM Router Alert option is 
invisible to the MPLS Label-switched hops, and when the LSP finishes, it is 
only processed once.

I am also not sure I understand the suggested action behind this comment. Are 
you suggesting we add a pointer to that Section, or that exact paragraph to the 
Security Considerations? 


> 
> 2. I'm a bit surprised to realise that new definitions of Router Alert
> options are not routinely notified to the 6MAN WG.

We had run this through 6MAN, both on list and presenting twice in IETF 
meetings.

Thanks!

Carlos.

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

Re: [Gen-art] review of draft-ietf-mpls-ipv6-only-gap-03.txt

[Carlos Pignataro (cpignata)]

Many thanks, Francis, for this review! All nits acknowledged and fixed.

Thanks,

Carlos.

> On Oct 29, 2014, at 9:56 AM, Francis Dupont  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-mpls-ipv6-only-gap-03.txt
> Reviewer: Francis Dupont
> Review Date: 20141025
> IETF LC End Date: 20141027
> IESG Telechat date: unknown
> 
> Summary: Ready
> 
> Major issues: None
> 
> Minor issues: None
> 
> Nits/editorial comments:
> - ToC page 2 and 5 page 18: Acknowledgements -> Acknowledgments
> 
> - 3.2.6 page 8: singaling -> signaling
> 
> - 3.3.1 page 9: e.g. -> e.g.,
> 
> - 3.3.2.4.1 pages 11 and 12: the conclusion (Gap: None) doesn't seem
>  very in phase with the text. Perhaps it is another case of "out of scope
>  known gap"?
> 
> - 3.4.2 page 15 (UK vs US spelling): behaviour -> behavior
> 
> - 4 page 17: Identifed -> Identified
> 
> - 6 pages 18 and 19, Authors' Addresses page 26: I don't like
>  ISO IS 3166 two letter codes used in postal addresses but it seems
>  to be what the new RFC required...
> 
> Regards
> 
> francis.dup...@fdupont.fr
> 
> PS: I reviewed the 02 version but now the 03 was published so I updated
> my comments. rfcdiff shows 03 is better than 02 at the exception of:
> - in 3.3.1.1 page 9 perhaps a missing '<' as I can see:
>... (see xref
>target="LDP"/>).
> PPS: it could be useful to have a checklist of all RFCs which should
> be updated but it is more a task for the WG than something to put
> in the document (I don't follow the WG so I don't know if it already
> exists :-).

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

Re: [Gen-art] [mpls] review: draft-ietf-mpls-lsp-ping-relay-reply-04

[Carlos Pignataro (cpignata)]

Hi Lizhong,

Please also take into consideration the Ops Dir review of this doc, in which I 
have similar concerns as those from Joel.

There seem to be three major areas in discussion:
1. The scope of the problem being solved (i.e., which cases are solved, which 
are not, and which are the common cases)
2. The mechanism itself not working in many cases.
3. How this all works with IPv6 addresses (since your fix seems to cover the 
overlapping IPv4 private address case only)

Thanks,

Carlos.

> On Oct 22, 2014, at 10:05 AM, lizho@gmail.com wrote:
> 
> Joel, thank you for the review. We will send out a new version soon to 
> reflect the discussion.
> 
> Regards
> Lizhong 
> 
> 
> 
>> 在 2014年10月22日，下午9:30，Joel Halpern Direct  wrote：
>> 
>> It would be good to see a revision that clearly spelled out what the
>> draft was solving, how the initial end-point knew what to create, and
>> how the responder knew what to use.  It may well be that there is an
>> effective solution to the problems here.  I look forward to seeing it in
>> writing.
>> 
>> Yours,
>> Joel
>> 
>>> On 10/22/14, 12:46 AM, Lizhong Jin wrote:
>>> Hi Joel,
>>> The things may not be that bad. You could add a second address (address B in
>>> our example) with K bit set. The address entry with K bit set must be as a
>>> relay node, and could not be skipped.
>>> Section 4.4 should be changed to: Find the first routable address A, and the
>>> first address B with K bit set. If address A is before address B in the
>>> stack, then use address B as the relay address. Otherwise, use address A as
>>> the relay address.
>>> In that case, if A is the private address, the packet will be firstly
>>> relayed to address B. And address A and B belong to one router. Here I
>>> assume one router at least has one routable address for another AS.
>>> 
>>> Regards
>>> Lizhong
>>> 
 -Original Message-
 From: Joel M. Halpern [mailto:j...@joelhalpern.com]
 Sent: 2014年10月22日 11:14
 To: Lizhong Jin
 Cc: gen-art@ietf.org; m...@ietf.org; i...@ietf.org;
>>> 'draft-ietf-mpls-lsp-ping-
 relay-reply.all'
 Subject: Re: [mpls] [Gen-art] review:
>>> draft-ietf-mpls-lsp-ping-relay-reply-04
 
 ou are saying that this is only for the case where an AS is using public
 addresses for its internal numbering, but is not distributing that address
>>> block
 externally?
 
 If so, you need to state that very clearly.
 I believe a far more common case is one where the numbering is from a
 portion of a publicly allocated space, but firewalled.  Which would
>>> produce
 the same problem, but would not be amenable to this solution.
 And it is well known that many ISPs do internal number assignment from
 private blocks.
 
 So what you are now saying is that this draft solves a very small portion
>>> of the
 problem?  But it works for that small portion?  If so, at the very least
>>> you
 need to be VERY clear about what cases this works for and what cases it
>>> does
 not.  And I fear that even if you are clear, it is going to be very
>>> confusing for
 folks who are trying to use it.
 
 Yours,
 Joel
 
> On 10/21/14, 10:51 PM, Lizhong Jin wrote:
> Hi Joel,
> I now see your concern. The "private" word in draft is not correct, I
> will remove it. The original motivation of "draft-relay-reply" is from
> the scenario where IP address distribution is restricted among AS or IGP
 area.
> And the IP address is not private address. As I know, most deployed
> inter-AS or inter-area MPLS LSP is in the network without private IP
>>> address.
> 
> Regards
> Lizhong
> 
> 
>> -Original Message-
>> From: Joel M. Halpern [mailto:j...@joelhalpern.com]
>> Sent: 2014年10月22日 10:15
>> To: Lizhong Jin
>> Cc: gen-art@ietf.org; m...@ietf.org; i...@ietf.org;
> 'draft-ietf-mpls-lsp-ping-
>> relay-reply.all'
>> Subject: Re: [mpls] [Gen-art] review:
> draft-ietf-mpls-lsp-ping-relay-reply-04
>> 
>> The problem is that the original source A, that we are trying to
>> reach
> with a
>> reply, has an address that appears to the responder X to be routable.
>> But the destination that is reached by that address is either a black
>> hole or
> some
>> other entity using the same address.
>> 
>> The reason for the duplication is that, as described in the draft,
>> the
> source
>> address for A is a private address.  That same address may well be
> reachable
>> according to the routing table at X.  But it won't get to A.
>> 
>> If the problem is something other than private addressing preventing
>> reachability, it is likely there is still a mistaken routability
>> problem,
> but I can
>> not illustrate the failure without some other case being described.
>> 
>> Yours,
>> Joel
>> 
>>> On 10/21/14, 10:06 PM, Lizhon

[Gen-art] Fwd: Gen-ART Telechat review of draft-ietf-opsec-ip-options-filtering-05.txt

[Carlos Pignataro (cpignata)]

Closing the loop on this Gen-ART review.

Thanks again Suresh for reviewing.

Thumb typed by Carlos Pignataro.
Excuze typofraphicak errows

Begin forwarded message:

From: Suresh Krishnan 
mailto:suresh.krish...@ericsson.com>>
Date: November 18, 2013 at 4:12:19 PM EST
To: "Carlos Pignataro (cpignata)" 
mailto:cpign...@cisco.com>>, RJ Atkinson 
mailto:rja.li...@gmail.com>>
Cc: Fernando Gont mailto:fg...@si6networks.com>>
Subject: Re: Gen-ART Telechat review of 
draft-ietf-opsec-ip-options-filtering-05.txt

Hi Carlos/Ran,
 This text looks good to me. Thanks for taking care of this quickly.

Regards
Suresh

On 11/18/2013 10:21 AM, Carlos Pignataro (cpignata) wrote:
Looks good, thank you Ran. I will incorporate this in our live
copy.

Suresh, any concerns?

Thanks,

-- Carlos.

On Nov 18, 2013, at 10:07 AM, RJ Atkinson 
mailto:rja.li...@gmail.com>>
wrote:


On 18  Nov 2013, at 09:41 , Carlos Pignataro (cpignata) wrote:
Here's the complete proposal for the complete Section 4.12.5
(and equivalent for 4.13.5).

Does this work? Please let me know and I can incorporate:

A lightly edited version follows -- edited mainly to reduce
redundant/ duplicative text and to retain phrasing "because the
IP packet contains this option" that was added in an earlier
round of review.

--- 4.12.5.  Advice

A given IP router, security gateway, or firewall has no way to
know a priori what environment it has been deployed into.  Even
closed IP deployments generally use exactly the same commercial
routers, security gateways, and firewalls that are used in the
public Internet.

Since operational problems result in environments where this
option is needed if either the option is dropped or IP packets
containing this option are dropped, but no harm results if the
option is carried in environments where it is not needed, the
default configuration SHOULD NOT (a) modify or remove this IP
option or (b) drop an IP packet because the IP packet contains
this option.

A given IP router, security gateway, or firewall MAY be
configured to drop this option or to drop IP packets containing
this option in an environment known to not use this option.

For auditing reasons, Routers, security gateways, and firewalls
SHOULD be capable of logging the numbers of packets containing
the BSO on a= per-interface basis.  Also, Routers, security
gateways, and firewalls SHOULD be capable of dropping packets
based on the BSO presence as well as the BSO values. ---

Similar text, edited to reflect "ESO" rather than "BSO", should
replace the existing advice about the IPSO ESO.

Cheers,

Ran




___
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-opsec-ip-options-filtering-05.txt

[Carlos Pignataro (cpignata)]

Jari,

Yes, Suresh and I/authors have already agreed on changes that I have 
incorporated into our working copy. 

Apologies for not closing the loop with you, will forward. 

Thanks!

Thumb typed by Carlos Pignataro.
Excuze typofraphicak errows

> On Nov 21, 2013, at 6:49 AM, "Jari Arkko"  wrote:
> 
> Suresh: thank you very much for the review. Carlos: I assume you and Joel 
> have the token on ensuring that changes, if any, get folded in before the 
> document is shipped to the RFC editor. I have balloted a no-obj position for 
> this draft.
> 
> By the way, I agree with the points that Suresh raised.
> 
> Jari
> 
>> On Nov 18, 2013, at 11:31 AM, Carlos Pignataro (cpignata) 
>>  wrote:
>> 
>> Many thanks for your review, Suresh. We will propose resolutions to these 
>> three comments you make.
>> 
>> Thanks,
>> 
>> -- Carlos.
>> 
>>> On Nov 18, 2013, at 12:54 AM, Suresh Krishnan 
>>>  wrote:
>>> 
>>> I have been selected as the General Area Review Team (Gen-ART) reviewer
>>> for this draft (for background on Gen-ART, please see
>>> http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html).
>>> 
>>> Please wait for direction from your document shepherd or AD before
>>> posting a new version of the draft.
>>> 
>>> Document: draft-ietf-opsec-ip-options-filtering-05.txt
>>> Reviewer: Suresh Krishnan
>>> Review Date: 2013/11/17
>>> IESG Telechat date: 2013/11/21
>>> 
>>> Summary: This draft is almost ready for publication as a BCP but
>>> I do have some issues that you may wish to consider
>>> 
>>> * Sections 4.12.5 and 4.13.5
>>> 
>>> Since these options are supposed to be used in closed environments,
>>> how likely are these options to appear in the wild? Even if they do,
>>> isn’t it a symptom of a misconfiguration somewhere. Given this, I
>>> would have expected the recommendation to read
>>> 
>>> Routers, security gateways, and firewalls … SHOULD by default drop
>>> packets because they contain this option…
>>> 
>>> but the recommendation is “SHOULD NOT by default”. I think It would
>>> be good if there was some reasoning attached to this recommendation.
>>> Without such reasoning, I think this recommendation will probably not
>>> be followed.
>>> 
>>> * Section 4.22.5
>>> 
>>> Have you considered that the default behavior for the option could be 
>>> related
>>> to the option class. E.g. Class 2 would default to ignore and forward and
>>> class 0 would default to drop and log.
>>> 
>>> * Section 4.23.4
>>> 
>>> It would be good to specify a default for this knob.
>>> 
>>> Thanks
>>> Suresh
>> 
>> ___
>> 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 Telechat review of draft-ietf-opsec-ip-options-filtering-05.txt

[Carlos Pignataro (cpignata)]

Many thanks for your review, Suresh. We will propose resolutions to these three 
comments you make.

Thanks,

-- Carlos.

On Nov 18, 2013, at 12:54 AM, Suresh Krishnan  
wrote:

> I have been selected as the General Area Review Team (Gen-ART) reviewer
> for this draft (for background on Gen-ART, please see
> http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html).
>  
> Please wait for direction from your document shepherd or AD before
> posting a new version of the draft.
>  
> Document: draft-ietf-opsec-ip-options-filtering-05.txt
> Reviewer: Suresh Krishnan
> Review Date: 2013/11/17
> IESG Telechat date: 2013/11/21
>  
> Summary: This draft is almost ready for publication as a BCP but
> I do have some issues that you may wish to consider
>  
> * Sections 4.12.5 and 4.13.5
>  
> Since these options are supposed to be used in closed environments,
> how likely are these options to appear in the wild? Even if they do,
> isn’t it a symptom of a misconfiguration somewhere. Given this, I
> would have expected the recommendation to read
>  
> Routers, security gateways, and firewalls … SHOULD by default drop
> packets because they contain this option…
>  
> but the recommendation is “SHOULD NOT by default”. I think It would
> be good if there was some reasoning attached to this recommendation.
> Without such reasoning, I think this recommendation will probably not
> be followed.
>  
> * Section 4.22.5
>  
> Have you considered that the default behavior for the option could be related
> to the option class. E.g. Class 2 would default to ignore and forward and
> class 0 would default to drop and log.
>  
> * Section 4.23.4
>  
> It would be good to specify a default for this knob.
>  
> Thanks
> Suresh



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-gp-obsolete-icmp-types-iana-01

[Carlos Pignataro (cpignata)]

Many thanks for the review, Roni.

On Jan 21, 2013, at 6:30 AM, Roni Even 
mailto:ron.even@gmail.com>> 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-gp-obsolete-icmp-types-iana-01
Reviewer: Roni Even
Review Date:2013–1–21
IETF LC End Date: 2013-2–14
IESG Telechat date:

Summary: This draft is ready for publication as Standard track RFC.


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 telechat review of draft-ietf-mpls-ipv6-pw-lsp-ping-03.txt

[Carlos Pignataro (cpignata)]

Thanks much for the review, Brian!

-- Carlos.

On 11/9/12 2:49 PM, "Brian E Carpenter" 
wrote:

>Please see attached review.
>
> Brian
>
>

___
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-mpls-ipv6-pw-lsp-ping-03.txt

[Carlos Pignataro (cpignata)]

Thank you, Brian!

Thumb typed by Carlos Pignataro.
Excuze typofraphicak errows

On Oct 30, 2012, at 7:02 AM, "Brian E Carpenter"  
wrote:

> Please see attached review.
> 
> Brian
> 
> 
___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

Re: [Gen-art] Gen-ART review: draft-ietf-pwe3-pw-typed-wc-fec-03

[Carlos Pignataro (cpignata)]

Thank you Mary for the review and for catching all these editorials!

Thumb typed by Carlos Pignataro.
Excuze typofraphicak errows

On Apr 9, 2012, at 3:22 PM, "Mary Barnes"  wrote:

> I am the assigned Gen-ART reviewer for this draft. For background on
> Gen-ART, please see the FAQ at
> < http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.
> 
> Please wait for direction from your document shepherd
> or AD before posting a new version of the draft.
> 
> Document: draft-ietf-pwe3-pw-typed-wc-fec-03.txt
> Reviewer:  Mary Barnes 
> Review Date:  9 April 2012
> IESG Telechat Date: 12 April 2012
> 
> Summary:  Ready with nits.
> 
> Comments: there are some editorial nits, many summarized below.  There are 
> several cases where an article - i.e., "the", "an", etc. is missing.   I 
> believe these can be fixed in AUTH48 and I imagine the RFC editor will catch 
> them. But, if the doc needs any other updates, it would be good to make these 
> fixes at the same time.  
> 
> Nits:
> -
> Section 1: 
> - first paragraph, second sentence is very awkward and could be rewritten 
> something like (unless I've misunderstood the objective of that sentence:
> OLD:
>This can be used when it is 
>desired to request all label bindings for a given type of FEC 
>Element, or to release or withdraw all label bindings for a given 
>type of FEC element. 
> NEW: 
>This can be used to request, release or withdraw all label 
>bindings for a given type of FEC element.
> 
> - second paragraph, last sentence - missing articles (PWID, same)
> OLD:
>The procedures for Typed Wildcard processing for PWid and  
>Generalized PWid FEC Elements are same as described in [RFC5918] for 
>any typed wildcard FEC Element type.
> NEW: 
>The procedures for Typed Wildcard processing for the PWid and  
>Generalized PWid FEC Elements are the same as described in [RFC5918] for 
>any typed wildcard FEC Element type.
> 
> Section 3:
> - third paragraph, last sentence before list: 
> OLD: 
>  provide 
>   more generalized and comprehensive solution by allowing: 
> NEW: 
>   provide a
>   more generalized and comprehensive solution by allowing: 
> 
> - list item 2: "constraint" -> "constrain"
> 
> 
> 
> Section 4.1: 
> OLD:
>  "… had learnt from LSR B over LDP session."
> NEW: 
>  " … learned from the LSR B over the LDP session."
> 
> OLD:
>  "…such request…" 
> NEW:
>  "…such a request…"  OR "..the request…"
> 
> OLD: 
>  (no stale)
> NEW: 
>  (not stale)
> 
> OLD:
>   completes consistency check
> NEW:
>   completes the consistency check
> 
> Section 4.3: 
> - first paragraph, last sentence:  
> OLD: 
>   with large number
> NEW:
>   with a large number
> 
> Section 4.4:
> - 1st para, 2nd sentence:
> OLD: 
>These procedures use LDP Address Withdraw message
> NEW: 
>These procedures use an LDP Address Withdraw message
> 
> - 2nd paragraph, last sentence:
> OLD:
>   This per PW (VPLS instance) MAC Withdraw messages 
> NEW: 
>   These per PW (VPLS instance) MAC Withdraw messages 
> 
> 3rd paragraph - 1st sentence:
> OLD:
>   this document allows use of
> NEW: 
>   this document allows the use of
___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

Re: [Gen-art] Gen-ART review of draft-atlas-icmp-unnumbered-08

[Carlos Pignataro (cpignata)]

David,

I think we are converging. To re-state, from my perspective:

1. ifIndex -- I think that adding a sentence describing different
potential uses of ifIndex inside and outside a management domain (esp.
its use outside) should be fine. I do not think it adds great value, but
it might not be as evident as it appeared.

2. C-Type -- No change needed. The only Normative reference outside the
very-well-known ones is RFC 4884, so it would be an easy choice on which
normative RFC to follow. Still, I do not mind a citation in the 1st line
of S4.1, like "For this object, the c-type _[RFC4884]_ is used", or a
parenthetical "see S8 of [RFC4884]", but I do not want a definition of
C-Type in this doc.

3. Section 4.5 -- Sure, that editorial seems sensible to me.

Thank you again for your review,

-- Carlos.

-Original Message-
From: black_da...@emc.com [mailto:black_da...@emc.com] 
Sent: Monday, December 28, 2009 3:59 PM
To: Carlos Pignataro (cpignata)
Cc: alia.at...@bt.com; rbon...@juniper.net; jrriv...@alumni.calpoly.edu;
Naiming Shen (naiming); gen-art@ietf.org; jari.ar...@piuha.net;
black_da...@emc.com
Subject: RE: Gen-ART review of draft-atlas-icmp-unnumbered-08

Carlos,

Summarizing ...

-- ifIndex --

> For the record, my main objection was to designing an traceroute +
SNMP
> Manager application querying an SNMP agent, etc, etc.

That was never my intent.  I believe my current request is to explain
something along the lines of the following in Section 3:

>>> A public use of the ifIndex can be to see different interfaces in a
>>> router, seeing ECMPs with unnumbered, and not mapping them to an
>>> interface name with an SNMP manager. That is a degree of
identification,
>>> to know they are different.

In other words, the ifIndex can be effectively used as an opaque token
to identify whether two ICMP messages involve the same interface
(ifIndex
values match) or not (ifIndex values are different).  I remain of the
opinion that this ability to use ifIndex outside of SNMP is both
somewhat
unexpected and important enough to mention, especially as the definition
of ifIndex is via reference to a MIB RFC.

-- C-Type --

This was a readability nit, no change is necessary.  I noted it because
when I reached the start of Section 4.1 in reviewing the draft, it was
not clear to me where C-Type was defined.  That sent me scurrying off
to go find its definition in order to understand the contents of
Section 4.1.  Unlike you, I did not know which RFC to check first.

-- Section 4.5 --

Trying to limit edits to the current text, try this ...

OLD
   A single instance of IP Address information MAY be included only in
   the following circumstances:
NEW (remove "only", add object)
   A single instance of IP Address information MAY be included in
   an Interface Information Object under the following circumstances:

After the two bullet items, add the following sentence to impose the
restriction to those circumstances.

NEW
   In all other circumstances, IP address information MUST NOT be
   included.


Thanks,
--David


> -Original Message-
> From: Carlos Pignataro [mailto:cpign...@cisco.com]
> Sent: Monday, December 28, 2009 2:50 PM
> To: Black, David
> Cc: alia.at...@bt.com; rbon...@juniper.net;
jrriv...@alumni.calpoly.edu; naim...@cisco.com; gen-
> a...@ietf.org; jari.ar...@piuha.net
> Subject: Re: Gen-ART review of draft-atlas-icmp-unnumbered-08
> 
> David,
> 
> I tried to convey as clearly as I could the reasons why I feel
strongly
> that what you suggested was not a good idea for the document. Sorry
for
> the carried away, it was an attempt at extra clarity. I think the new
> twist can be of help, and the counter-suggestion won't hurt.
> 
> Please see inline my additional $0.005, then I will let others chime
in
> with their thoughts.
> 
> On 12/28/2009 1:59 PM, black_da...@emc.com wrote:
> > Carlos,
> >
> > I think you're getting carried away.  I would like to see some text
> > explaining why the ifIndex is useful in Section 3 rather than having
> > to go all the way down to the Security Considerations section to
> > figure out what it's useful for.  It doesn't need to involve SNMP,
> > more below ...
> >
> >> I disagree with the intrinsic '"public"' nature and the 'clearly'
use
> >> you mention; and so does the I-D, as the Security Considerations
> > section
> >> explicitly negates what you are saying here.
> >
> > I don't think so.  In order to restrict use of this extension to
within
> > an operator's network in all cases, the Security Considerations
section
> > would have to contain a MUST or MUST NOT requirement that is not
> > present.
> >
> > I suppose adding such a requirement could be an

Re: [Gen-art] Gen-ART review of draft-atlas-icmp-unnumbered-08

[Carlos Pignataro]

 Address information MAY be included only in
>>   the following circumstances:
> 
> IMHO, the paragraph break makes it not self-evident.  
> 
>> We can s/be included/be included in an Interface Information Object/
> at
>> expense of being repetitive.
> 
> I would do that, as it's clearer.  As an alternative, remove the
> paragraph
> break.

OK, I agree, and I think that the addition of "in an Interface
Information Object" is the most clear modification.

> 
>>> I presume an Interface Information Object.  Also,
>>>MAY ... only is poor usage of RFC 2119 terminology.
>> Why? We are saying that the item (an IP Address information element)
> is
>> truly optional,
> 
> If that's what was truly meant, then "only in the following
> circumstances:"
> and the two bullet items following it need to be removed because they
> place significant restrictions on when the item can be included, making
> it
> not truly optional.
> 
>> and the definition of MAY says:
>>
>>   5. MAY This word, or the adjective "OPTIONAL", mean that an item is
>>  truly optional...
>>
>> So how is the usage poor?
> 
> Read the *rest* of RFC 2119 (!).  The keywords MUST, MUST NOT, SHOULD,
> SHOULD NOT and MAY are defined there, but MAY NOT is omitted.  The
> latter
> is a deliberate omission, as MAY NOT is ambiguous and bad standards
> language
> (e.g., MAY is equivalent to "may or may not").  The draft's text uses a
> "MAY ... only in the following circumstances" construction, which is an
> ambiguous variant of MAY NOT.  I understand what was meant, but in order
> to use RFC 2119 keywords to correctly impose the two "only in the
> following
> circumstances" requirements, a MUST (or a MUST NOT) is appropriate,
> e.g.,

I still read that: "in the following circumstances, it is truly optional
to include the IP Address". As in, given this initial conditions, you
MAY do it. But rephrases that won't alter the semantics are welcome.

Thanks,

-- Carlos.

> 
>>>When an Interface Information Object contains an IP Address, one
> of
>>>the following two conditions MUST be true:
> 
> Thanks,
> --David
> 
>> -Original Message-
>> From: Carlos Pignataro [mailto:cpign...@cisco.com]
>> Sent: Monday, December 28, 2009 11:58 AM
>> To: Black, David
>> Cc: alia.at...@bt.com; rbon...@juniper.net; JR Rivers;
> naim...@cisco.com; gen-art@ietf.org;
>> jari.ar...@piuha.net
>> Subject: Re: Gen-ART review of draft-atlas-icmp-unnumbered-08
>>
>> [apologize, hit send too quickly, wanted to add:]
>>
>> public traceroute reports:
>>
>> 10  namehidden1 (ipaddress1)  20 ms  55 ms  36 ms
>> MPLS Label=698653 Exp=0 TTL=1 S=0
>> MPLS Label=301856 Exp=0 TTL=1 S=1
>> 11  namehidden2 (ipaddress2)  45 ms  52 ms  50 ms
>> MPLS Label=323717 Exp=0 TTL=1 S=0
>> MPLS Label=301856 Exp=0 TTL=2 S=1
>>
>> But RFC4950 does not prescribe a traceroute + LIB/LFIB manager, which
> I
>> think would be analogous.
>>
>> Thanks,
>>
>> -- Carlos.
>>
>> On 12/28/2009 11:48 AM, Carlos Pignataro wrote:
>>> David,
>>>
>>> Please find one additional comment response to your suggestion.
>>>
>>> Excerpts from black_da...@emc.com on 12/27/2009:
>>>> I suggest adding a Section 3.3 to discuss use of ifIndex with ICMP
> and
>>>> network management tools (e.g., enhanced traceroute plus an SNMP
>>>> manager)
>>> I still feel that discussing this use would be a strong distraction
> and
>>> divertion, and not add substativeness to the spec, ultimatelly
> causing
>>> confusion.
>>>
>>> My traceroute app at home does IP address-to-name mapping, querying
> DNS
>>> and reporting hostnames; ICMP timexceeded was not spec'ed that way,
> but
>>> a 'traceroute + hostname manager querier' was useful. It also does:
>>>   -A: Report AS# at each hop (from GRR)
>>>   -O: Report owner at each hop (from DNS)
>>>
>>> because it was useful, and reports TOS change, none of which was
>>> including on the ICMP timeexceeded or unreachable definitions.
>>>
>>> A public use of the ifIndex can be to see different interfaces in a
>>> router, seeing ECMPs with unnumbered, and not mapping them to an
>>> interface name with an SNMP manager. That is a degree of
> idenfication,
>>> to know they are different.
>>>
>>> Describing an app like you suggest would implicitly limit, I think.
> We
>>> are not spec'ing an application, only the extensions of ICMP, and it
>>> seems to me that there is enough contextual applicability and
> motivation
>>> (without falling into over-framing and under-scoping).
>>>
>>> Thanks,
>>>
>>> -- Carlos.
>>>
> 
> 
___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

Re: [Gen-art] Gen-ART review of draft-atlas-icmp-unnumbered-08

[Carlos Pignataro]

[apologize, hit send too quickly, wanted to add:]

public traceroute reports:

10  namehidden1 (ipaddress1)  20 ms  55 ms  36 ms
MPLS Label=698653 Exp=0 TTL=1 S=0
MPLS Label=301856 Exp=0 TTL=1 S=1
11  namehidden2 (ipaddress2)  45 ms  52 ms  50 ms
MPLS Label=323717 Exp=0 TTL=1 S=0
MPLS Label=301856 Exp=0 TTL=2 S=1

But RFC4950 does not prescribe a traceroute + LIB/LFIB manager, which I
think would be analogous.

Thanks,

-- Carlos.

On 12/28/2009 11:48 AM, Carlos Pignataro wrote:
> David,
> 
> Please find one additional comment response to your suggestion.
> 
> Excerpts from black_da...@emc.com on 12/27/2009:
>> I suggest adding a Section 3.3 to discuss use of ifIndex with ICMP and
>> network management tools (e.g., enhanced traceroute plus an SNMP
>> manager)
> 
> I still feel that discussing this use would be a strong distraction and
> divertion, and not add substativeness to the spec, ultimatelly causing
> confusion.
> 
> My traceroute app at home does IP address-to-name mapping, querying DNS
> and reporting hostnames; ICMP timexceeded was not spec'ed that way, but
> a 'traceroute + hostname manager querier' was useful. It also does:
>   -A: Report AS# at each hop (from GRR)
>   -O: Report owner at each hop (from DNS)
> 
> because it was useful, and reports TOS change, none of which was
> including on the ICMP timeexceeded or unreachable definitions.
> 
> A public use of the ifIndex can be to see different interfaces in a
> router, seeing ECMPs with unnumbered, and not mapping them to an
> interface name with an SNMP manager. That is a degree of idenfication,
> to know they are different.
> 
> Describing an app like you suggest would implicitly limit, I think. We
> are not spec'ing an application, only the extensions of ICMP, and it
> seems to me that there is enough contextual applicability and motivation
> (without falling into over-framing and under-scoping).
> 
> Thanks,
> 
> -- Carlos.
> 
___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

Re: [Gen-art] Gen-ART review of draft-atlas-icmp-unnumbered-08

[Carlos Pignataro]

David,

Please find one additional comment response to your suggestion.

Excerpts from black_da...@emc.com on 12/27/2009:
> I suggest adding a Section 3.3 to discuss use of ifIndex with ICMP and
> network management tools (e.g., enhanced traceroute plus an SNMP
> manager)

I still feel that discussing this use would be a strong distraction and
divertion, and not add substativeness to the spec, ultimatelly causing
confusion.

My traceroute app at home does IP address-to-name mapping, querying DNS
and reporting hostnames; ICMP timexceeded was not spec'ed that way, but
a 'traceroute + hostname manager querier' was useful. It also does:
  -A: Report AS# at each hop (from GRR)
  -O: Report owner at each hop (from DNS)

because it was useful, and reports TOS change, none of which was
including on the ICMP timeexceeded or unreachable definitions.

A public use of the ifIndex can be to see different interfaces in a
router, seeing ECMPs with unnumbered, and not mapping them to an
interface name with an SNMP manager. That is a degree of idenfication,
to know they are different.

Describing an app like you suggest would implicitly limit, I think. We
are not spec'ing an application, only the extensions of ICMP, and it
seems to me that there is enough contextual applicability and motivation
(without falling into over-framing and under-scoping).

Thanks,

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

Re: [Gen-art] Gen-ART review of draft-atlas-icmp-unnumbered-08

[Carlos Pignataro]

[adding JR to Cc:]

On 12/27/2009 6:02 PM, black_da...@emc.com wrote:
> And the draft needs a new email address for JR:

Yes, we will fix this before publication.

Thanks again,

-- Carlos.

> 
> Your message did not reach some or all of the intended recipients.
> 
>   Subject:Gen-ART review of draft-atlas-icmp-unnumbered-08
>   Sent:   12/27/2009 5:53 PM
> 
> The following recipient(s) cannot be reached:
> 
>   jrriv...@cisco.com on 12/27/2009 5:54 PM
> The e-mail system was unable to deliver the message, but did
> not report a specific reason.  Check the address and try again.  If it
> still fails, contact your system administrator.
> < sj-inbound-d.cisco.com #5.0.0 smtp; 5.1.0 - Unknown
> address error 550-'5.1.1 ... User unknown' (delivery
> attempts: 0)>
> 
> 
> Thanks,
> --David
> 
> 
>> -Original Message-
>> From: Black, David
>> Sent: Sunday, December 27, 2009 5:53 PM
>> To: alia.at...@bt.com; rbon...@juniper.net; cpign...@cisco.com;
> jrriv...@cisco.com; naim...@cisco.com;
>> 'gen-art@ietf.org'
>> Cc: Jari Arkko; Black, David
>> Subject: Gen-ART review of draft-atlas-icmp-unnumbered-08
>>
>> I have been selected as the General Area Review Team (Gen-ART)
>> reviewer for this draft (for background on Gen-ART, please see
>> http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html).
>>
>> Please resolve these comments along with any other Last Call
>> comments you may receive.
>>
>> Document: draft-atlas-icmp-unnumbered-08
>> Reviewer: David L. Black
>> Review Date: December 27, 2009
>> IETF LC End Date: January 1, 2010
>>
>> Summary:
>> This draft is on the right track, but has open issues, described
>> in the review.
>>
>> Comments:
>> The draft defines an extension to ICMP messages that allows additional
>> network interface information to be provided with some ICMP messages.
>> The information may be an ifIndex, an IP address, an Interface Name
>> and/or an MTU.
>>
>> The one open issue in this review involves the use of ifIndex to
>> identify an interface.  The motivating use cases in section 3
>> involve traceroute, ACL-caused-blockage, and the need to determine the
>> MTU - those use cases are "public" in the sense that they clearly
>> encompass use of the ICMP messages by other than the network operator
>> whose device generated those messages.
>>
>> In this context, IP address, Interface Name and MTU are all clearly
>> useful, but I am concerned about ifIndex.  An ifIndex is effectively
>> private to the SNMP management infrastructure of the network operator.
>> Determining what interface an ifIndex designates generally involves
>> SNMP access that a network operator may be reluctant to grant to
>> outsiders due to the level of detail that such access may expose.
>>
>> I suspect that the ifIndex could be *very* useful to an ifIndex-
>> enhanced traceroute issued from a network operator's management
> station
>> as alluded to in paragraphs 3-5 of Section 6 (Security
> Considerations).
>> My open issue is that I should have to go all the way down to the
> latter
>> part of the Security Considerations section in order to find the
>> motivations for and intended usage of one of the major features of
> this
>> extension.
>>
>> I suggest adding a Section 3.3 to discuss use of ifIndex with ICMP and
>> network management tools (e.g., enhanced traceroute plus an SNMP
> manager)
>> by a network operator to debug his/her own network.  This new section
>> should also contain some sort of warning that ifIndex information may
>> not be available to other than the network operator's management
>> applications (with a pointer to the Security Considerations section).
>>
>> Nits:
>> - Section 2: "o  that interface is numbered"  Please add a definition
>>  of "numbered" for an interface.
>> - Section 4.1: Explain what a C-Type is.  A few words and a reference
>>  to Section 8 of RFC 4884 should suffice.
>> - Section 5.4: This appears to be poorly stated:
>>A single instance of IP Address information MAY be included only in
>>the following circumstances:
>>
>>Included in what?  I presume an Interface Information Object.
> Also,
>>MAY ... only is poor usage of RFC 2119 terminology.  Here's an
> attempt
>>at better phrasing:
>>
>>When an Interface Information Object contains an IP Address, one of
>>the following two conditions MUST be true:
>>
>> idnits 2.11.15 did not find any nits.
>>
>> Thanks,
>> --David
>> 
>> David L. Black, Distinguished Engineer
>> EMC Corporation, 176 South St., Hopkinton, MA  01748
>> +1 (508) 293-7953 FAX: +1 (508) 293-7786
>> black_da...@emc.comMobile: +1 (978) 394-7754
>> 
> 
___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

Re: [Gen-art] Gen-ART review of draft-atlas-icmp-unnumbered-08

[Carlos Pignataro]

David,

Thank you for your time to review, please see inline.

On 12/27/2009 5:52 PM, black_da...@emc.com wrote:
> I have been selected as the General Area Review Team (Gen-ART) 
> reviewer for this draft (for background on Gen-ART, please see 
> http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html).
> 
> Please resolve these comments along with any other Last Call
> comments you may receive.
> 
> Document: draft-atlas-icmp-unnumbered-08
> Reviewer: David L. Black
> Review Date: December 27, 2009
> IETF LC End Date: January 1, 2010
> 
> Summary:
> This draft is on the right track, but has open issues, described
> in the review.
> 
> Comments:
> The draft defines an extension to ICMP messages that allows additional
> network interface information to be provided with some ICMP messages.
> The information may be an ifIndex, an IP address, an Interface Name
> and/or an MTU.
> 
> The one open issue in this review involves the use of ifIndex to
> identify an interface.  The motivating use cases in section 3
> involve traceroute, ACL-caused-blockage, and the need to determine the
> MTU - those use cases are "public" in the sense that they clearly
> encompass use of the ICMP messages by other than the network operator
> whose device generated those messages.

I disagree with the intrinsic '"public"' nature and the 'clearly' use
you mention; and so does the I-D, as the Security Considerations section
explicitly negates what you are saying here.

Moreover, the motivation is not (as you say) in the use cases in Section
3. The motivation is spelled out in the Introduction (ifIndex identifies
an unnumbered interface within the router). Section 3 provides exemplary
(and not all inclusive) use cases.

> 
> In this context, IP address, Interface Name and MTU are all clearly
> useful, but I am concerned about ifIndex.  An ifIndex is effectively
> private to the SNMP management infrastructure of the network operator.
> Determining what interface an ifIndex designates generally involves
> SNMP access that a network operator may be reluctant to grant to
> outsiders due to the level of detail that such access may expose.
> 
> I suspect that the ifIndex could be *very* useful to an ifIndex-
> enhanced traceroute issued from a network operator's management station
> as alluded to in paragraphs 3-5 of Section 6 (Security Considerations).
> My open issue is that I should have to go all the way down to the latter
> part of the Security Considerations section in order to find the
> motivations for and intended usage of one of the major features of this
> extension.

OK, so your open issue is that the security concern is addressed in the
Security Considerations? Existing text addresses your concern. We expect
implementors to read the complete spec, including the Security
Considerations. And folks will not implement a spec without
understanding its use.

The details: The motivation is in Section 1, Introduction:

   If all of the following conditions are true, the source address of
   the ICMPv4 message identifies the interface upon which the original
   datagram arrived:

   o  the device sends an ICMPv4 message through the same interface upon
  which the original datagram was received
   o  that interface is numbered

   However, the incoming and outgoing interfaces may be different due to
   an asymmetric return path, which can occur due to asymmetric link
   costs, parallel links or Equal Cost Multipath (ECMP).

and the concern you raise is explicitly addressed in the spec:

   It may be desirable to provide this information to a particular
   network's operators and not to others.

> 
> I suggest adding a Section 3.3 to discuss use of ifIndex with ICMP and
> network management tools (e.g., enhanced traceroute plus an SNMP
> manager)

Thank you for the suggestion.
I strongly disagree with this suggestion.

I highly suspect that doing so would be harmful to the spec, as it would
(implicitly) limit the scope of applicability and use of the extension.
We do not what to spell out potential uses in so much detail, as they
would become obsolete before the spec is. And we do not want to pretend
we cover all use cases.

> by a network operator to debug his/her own network.  This new section
> should also contain some sort of warning that ifIndex information may
> not be available to other than the network operator's management
> applications (with a pointer to the Security Considerations section).

This is understood from the definition (and _Normative_ citation
pointer) of ifIndex in the spec. It would be, IMHO, redundant and
therefore be another distraction to the reader.

> 
> Nits:
> - Section 2: "o  that interface is numbered"  Please add a definition
>   of "numbered" for an interface.

We could add a pointer to [RFC1812], although I really do not think it
is needed. There is ample precedence that this is not needed, e.g., OSPF
RFCs like RFC2328, RFC5185, etc, etc.

> - Section 4.1: Explain what a C-Type is.  A few words a

Re: [Gen-art] Gen-ART review of draft-ietf-bmwg-mpls-forwarding-meth-05.txt

[Carlos Pignataro (cpignata)]

Brian,

Many thanks for your review !

Ron, Brian,

Regarding the concern about 2119 keywords (Gen-ART issue 1), I wonder if doing 
away with them would be too drastic, considering that all the more recent bmwg 
methodology RFC and I-Ds do use them. I agree that the cases that were 
highlighted need fixing.
Regarding issue 2: good point, we will fix it saying explicitly why cases 6-8 
are not covered.

Thanks,

-- Carlos.

-Original Message-
From: Brian E Carpenter [mailto:brian.e.carpen...@gmail.com] 
Sent: Tuesday, August 25, 2009 9:55 PM
To: Ron Bonica
Cc: Aamer Akhter (aakhter); General Area Review Team; 
bmwg-cha...@tools.ietf.org; Rajiv Asati (rajiva); Carlos Pignataro (cpignata)
Subject: Re: Gen-ART review of draft-ietf-bmwg-mpls-forwarding-meth-05.txt

This is a manual repeat as I have been getting error messages
from the tools server on the authors' address alias.

Hi Ron,

That would work for me. However, I don't see this as a show-stopper
necessarily; it depends whether the IESG wants to be picky about
this issue for an Informational. Not my call.

   Brian



On 2009-08-25 03:11, Ron Bonica wrote:
> Could we address this issue dispensing with 2119 language altogether
> (i.e. convert to lower case).
> 
>  Ron
> 
> 
> Brian E Carpenter wrote:
> 

___
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-softwire-lb-03

[Carlos Pignataro (cpignata)]

Thanks again, Avshalom, for the comments (that improve the document)  
and for taking the time to review!


--
Thumb typed by Carlos Pignataro.

On Jul 6, 2009, at 11:18 AM, "Avshalom Houri"   
wrote:



Hi Carlos,

OK with me as long as everyone that is familiar with the field  
understand why this change does not introduce new security risks.


Thanks
--Avshalom




From:   "Carlos Pignataro (cpignata)" 
To: Avshalom Houri/Haifa/i...@ibmil
Cc:	"Clarence Filsfils (cfilsfil)" , "General  
Area Review Team" , "Pradosh Mohapatra (pmohapat)"  
, "Ralph Droms (rdroms)" 

Date:   06/07/2009 06:07 PM
Subject:RE: Gen Art review of draft-ietf-softwire-lb-03




Hi Avshalom,

I think that the phrase you added (copied from the email body) is  
well understood form the first new sentence for someone implementing  
this. I mean, the text:
“Since this document defines a very incremental addition of a sub-TL 
V, ”

Is implied (and sounds repetitive) from:
“This document defines a new sub-TLV for the BGP Tunnel Encapsulatio 
n Attribute.”


So instead of us qualifying the addition with “very incremental”,  
it is less ambiguous to quantify it with “a new sub-TLV for the BGP  
Tunnel Encapsulation Attribute”. IOH, the first sentence re-summariz 
es the extent of the change for the context of the Security paragraph.


Does this make sense?

Thanks,

-- Carlos. 


From: Avshalom Houri [mailto:avsha...@il.ibm.com]
Sent: Monday, July 06, 2009 10:58 AM
To: Carlos Pignataro (cpignata)
Cc: Clarence Filsfils (cfilsfil); General Area Review Team; Pradosh  
Mohapatra (pmohapat); Ralph Droms (rdroms)

Subject: Re: Gen Art review of draft-ietf-softwire-lb-03

Maybe like this?

4.  Security Considerations

+   This document defines a new sub-TLV for the BGP Tunnel  
Encapsulation

+   Attribute.  Security considerations for the BGP Encapsulation SAFI
+   and the BGP Tunnel Encapsulation Attribute are covered in  
[RFC5512].

+   Since this document defines a very incremental addition of a
+   sub-TLV, there are no additional security risks introduced by  
this design.


Thanks
--Avshalom

From:   Carlos Pignataro 
To: Avshalom Houri/Haifa/i...@ibmil
Cc:	cfils...@cisco.com, pmoha...@cisco.com, General Area Review Team  
, rdr...@cisco.com

Date:   06/07/2009 05:43 PM
Subject:Re: Gen Art review of draft-ietf-softwire-lb-03







Avshalom,

Thank you for your review. As you identified, it would be useful to  
cite

the applicable security considerations that are documented and
inherited. I think that the following change would address your
concerns. This document defines a very incremental addition of a
sub-TLV, it would seem that further elaboration would be redundant:

4.  Security Considerations

+   This document defines a new sub-TLV for the BGP Tunnel  
Encapsulation

+   Attribute.  Security considerations for the BGP Encapsulation SAFI
+   and the BGP Tunnel Encapsulation Attribute are covered in  
[RFC5512].

  There are no additional security risks introduced by this design.

Please let us know if this addresses your concerns.

Thanks,

-- Carlos.

On 7/2/2009 9:00 AM, Avshalom Houri wrote:
> I have been selected as the General Area Review Team (Gen-ART)
> reviewer for this draft (for background on Gen-ART, please see
> http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html).
>
> Please resolve these comments along with any other Last Call  
comments

> you may receive.
>
> Document: draft-ietf-softwire-lb-03
> Reviewer: Avshalom Houri
> Review Date: 2009-07-02
> IETF LC End Date: 2009-07-03
> IESG Telechat date: (if known) --
>
> Summary: The document needs to update the security section in  
order to

> be ready for publication as a Proposed Standard.
>
> Major issues:
>
> Line 269:
>There are no additional security risks introduced by this design.
>
> - The above is the while text in the security considerations  
section.
> Please specify where the basic security discussion for this was  
done.
> Please also say in few words why do you think that no security  
issues

> are introduced in this document.
>
> Minor issues: None
>
> Nits/editorial comments: None
>
> Thanks
> --Avshalom
___
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-softwire-lb-03

[Carlos Pignataro (cpignata)]

Hi Avshalom,

 

I think that the phrase you added (copied from the email body) is well
understood form the first new sentence for someone implementing this. I
mean, the text:

"Since this document defines a very incremental addition of a sub-TLV, "

Is implied (and sounds repetitive) from:

"This document defines a new sub-TLV for the BGP Tunnel Encapsulation
Attribute."

 

So instead of us qualifying the addition with "very incremental", it is
less ambiguous to quantify it with "a new sub-TLV for the BGP Tunnel
Encapsulation Attribute". IOH, the first sentence re-summarizes the
extent of the change for the context of the Security paragraph. 

 

Does this make sense?

 

Thanks,

 

-- Carlos.

 

From: Avshalom Houri [mailto:avsha...@il.ibm.com] 
Sent: Monday, July 06, 2009 10:58 AM
To: Carlos Pignataro (cpignata)
Cc: Clarence Filsfils (cfilsfil); General Area Review Team; Pradosh
Mohapatra (pmohapat); Ralph Droms (rdroms)
Subject: Re: Gen Art review of draft-ietf-softwire-lb-03

 

Maybe like this? 

 4.  Security Considerations

+   This document defines a new sub-TLV for the BGP Tunnel Encapsulation
+   Attribute.  Security considerations for the BGP Encapsulation SAFI
+   and the BGP Tunnel Encapsulation Attribute are covered in [RFC5512].
+   Since this document defines a very incremental addition of a
+   sub-TLV, there are no additional security risks introduced by this
design. 

Thanks
--Avshalom




From: 

Carlos Pignataro  

To: 

Avshalom Houri/Haifa/i...@ibmil 

Cc: 

cfils...@cisco.com, pmoha...@cisco.com, General Area Review Team
, rdr...@cisco.com 

Date: 

06/07/2009 05:43 PM 

Subject: 

Re: Gen Art review of draft-ietf-softwire-lb-03

 






Avshalom,

Thank you for your review. As you identified, it would be useful to cite
the applicable security considerations that are documented and
inherited. I think that the following change would address your
concerns. This document defines a very incremental addition of a
sub-TLV, it would seem that further elaboration would be redundant:

4.  Security Considerations

+   This document defines a new sub-TLV for the BGP Tunnel Encapsulation
+   Attribute.  Security considerations for the BGP Encapsulation SAFI
+   and the BGP Tunnel Encapsulation Attribute are covered in [RFC5512].
   There are no additional security risks introduced by this design.

Please let us know if this addresses your concerns.

Thanks,

-- Carlos.

On 7/2/2009 9:00 AM, Avshalom Houri wrote:
> I have been selected as the General Area Review Team (Gen-ART)
> reviewer for this draft (for background on Gen-ART, please see
> http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html
<http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html> ).
> 
> Please resolve these comments along with any other Last Call comments
> you may receive.
> 
> Document: draft-ietf-softwire-lb-03
> Reviewer: Avshalom Houri
> Review Date: 2009-07-02
> IETF LC End Date: 2009-07-03
> IESG Telechat date: (if known) --
> 
> Summary: The document needs to update the security section in order to
> be ready for publication as a Proposed Standard.
> 
> Major issues:
> 
> Line 269:
>There are no additional security risks introduced by this design.
> 
> - The above is the while text in the security considerations section.
> Please specify where the basic security discussion for this was done.
> Please also say in few words why do you think that no security issues
> are introduced in this document.
> 
> Minor issues: None
> 
> Nits/editorial comments: None
> 
> Thanks
> --Avshalom

___
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-softwire-lb-03

[Carlos Pignataro]

Avshalom,

Thank you for your review. As you identified, it would be useful to cite
the applicable security considerations that are documented and
inherited. I think that the following change would address your
concerns. This document defines a very incremental addition of a
sub-TLV, it would seem that further elaboration would be redundant:

 4.  Security Considerations

+   This document defines a new sub-TLV for the BGP Tunnel Encapsulation
+   Attribute.  Security considerations for the BGP Encapsulation SAFI
+   and the BGP Tunnel Encapsulation Attribute are covered in [RFC5512].
There are no additional security risks introduced by this design.

Please let us know if this addresses your concerns.

Thanks,

-- Carlos.

On 7/2/2009 9:00 AM, Avshalom Houri wrote:
> I have been selected as the General Area Review Team (Gen-ART)
> reviewer for this draft (for background on Gen-ART, please see
> http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html).
> 
> Please resolve these comments along with any other Last Call comments
> you may receive.
> 
> Document: draft-ietf-softwire-lb-03
> Reviewer: Avshalom Houri
> Review Date: 2009-07-02
> IETF LC End Date: 2009-07-03
> IESG Telechat date: (if known) --
> 
> Summary: The document needs to update the security section in order to
> be ready for publication as a Proposed Standard.
> 
> Major issues:
> 
> Line 269:
>There are no additional security risks introduced by this design.
> 
> - The above is the while text in the security considerations section.
> Please specify where the basic security discussion for this was done.
> Please also say in few words why do you think that no security issues
> are introduced in this document.
> 
> Minor issues: None
> 
> Nits/editorial comments: None
> 
> Thanks
> --Avshalom
___
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-ospf-dynamic-hostname-04

[Carlos Pignataro (cpignata)]

Thanks for the validation, Spencer. We did discuss the level (I.e.,  
case) of the recommendation, and agreed in the lowercase "really good  
idea" qualified with "strongly".


Thanks,

--
Thumb typed by Carlos Pignataro.

On Jun 30, 2009, at 12:41 PM, "Spencer Dawkins" > wrote:



I have been selected as the General Area Review Team (Gen-ART)
reviewer for this draft (for background on Gen-ART, please see
http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html).

Please wait for direction from your document shepherd
or AD before posting a new version of the draft.

Document: draft-ietf-ospf-dynamic-hostname-04
Reviewer: Spencer Dawkins
Review Date: 30 June 2009
IESG Telechat date: 02 July 2009

Summary: This version of the draft addresses all of the issues I  
identified with version 03. This document is ready for publication  
as a Proposed Standard.


There is some new text in Section 3.1 that I wanted to ask about:

 The value field identifies the symbolic hostname of the router
 originating the LSA.  This symbolic name can be the FQDN for the
 router, it can be a subset of the FQDN, or it can be any string
 operators want to use for the router.  The use of FQDN or a subset of
 it is strongly recommended.

This being a Proposed Standard (when approved) that uses 2119  
language... did you mean "strongly RECOMMENDED", or just "a really  
good idea"?


But you guys can do the right thing without telling me what that  
is ...


Thanks,

Spencer



Hi, Carlos,

Both of your proposed issue resolutions work for me (and I agree  
about putting the duplicated hostname note in the Security  
Considerations section, and not in Section 3).


Thanks,

Spencer

- Original Message - From: "Carlos Pignataro" >

To: "Spencer Dawkins" 
Cc: "Sanjay Harwani (sharwani)" ; "Subbaiah  
Venkata" ; "Danny McPherson" ; >; "General Area Review Team" ; "Ross Callon" >; "Acee Lindem" ; "Abhay Roy (akr)"  


Sent: Friday, June 12, 2009 10:29 AM
Subject: Re: Gen-ART review of draft-ietf-ospf-dynamic-hostname-03



Hi Spencer,

Thank you for your review, please see inline.

On 6/12/2009 6:24 AM, Spencer Dawkins wrote:

Hi, Sanjay,

please see inline starting with SD:

And thanks for a quick response (before I leave for vacation  
today).


Spencer

- Original Message - From: "Sanjay Harwani (sharwani)" >
To: "Spencer Dawkins" ; "Subbaiah  
Venkata"
; "Danny McPherson" ; "Carlos  
Pignataro

(cpignata)" 
Cc: ; "General Area Review Team" a...@ietf.org>; "Ross
Callon" ; "Acee Lindem" ;  
"Abhay Roy

(akr)" 
Sent: Thursday, June 11, 2009 11:38 PM
Subject: RE: Gen-ART review of draft-ietf-ospf-dynamic-hostname-03


Adding in Carlos who holds the pen for us, Please see inline  
starting

with SH:

-Original Message-
From: Spencer Dawkins [mailto:spen...@wonderhamster.org]
Sent: Friday, June 12, 2009 3:55 AM
To: Subbaiah Venkata; Sanjay Harwani (sharwani); Danny McPherson
Cc: i...@ietf.org; General Area Review Team; Ross Callon; Acee  
Lindem;

Abhay Roy (akr)
Subject: Gen-ART review of draft-ietf-ospf-dynamic-hostname-03

I have been selected as the General Area Review Team (Gen-ART)  
reviewer

for this draft (for background on Gen-ART, please see
http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html).

Please resolve these comments along with any other Last Call  
comments

you may receive.

Document: draft-ietf-ospf-dynamic-hostname-03
Reviewer: Spencer Dawkins
Review Date: 2009-06-11
IETF LC End Date: 2009-06-16
IESG Telechat date: (not known)

Summary: This document is almost ready for publication as a  
Proposed

Standard. I identified two minor issues listed below.

2.  Possible solutions

  Another approach is having a centralized location where the  
name-to-

  Router ID mapping can be kept.  DNS can be used for the same.  A
  disadvantage with this centralized solution is that its a single

Spencer (nit): s/its/it's/


Ack -- fixed in the working copy.



  point of failure; and although enhanced availability of the  
central
  mapping service can be designed, it may not be able to resolve  
the
  hostname in the event of reachability or network problems.   
Also, the
  response time can be an issue with the centralized solution,  
which
  can be particularly problematic in times of problem  
resolution.  If


Spencer (minor): good point on response times, but I'd also think  
you'd
point out that looking up attributes on a centralized mapping  
table is

exactly the wrong thing to do when you're resolving problems with
routing - the centralized resource may not even be reachable.

SH: I think we already have it covered just above in the same  
paragraph.

(single point of failure)
   
A disadvantage with this centralized s

Re: [Gen-art] [L2tpext] Gen-ART Review of draft-ietf-l2tpext-circuit-status-extensions-04

[Carlos Pignataro]

Hello Pete,

Many thanks for your review. Please see inline.

On 6/15/2009 1:57 PM, McCann Peter-A001034 wrote:
> I have been selected as the General Area Review Team (Gen-ART) reviewer
> for this draft (for background on Gen-ART, please see
> http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html). 
> 
> Please resolve these comments along with any other Last Call comments
> you may receive. 
> 
> Document: draft-ietf-l2tpext-circuit-status-extensions-04
> Reviewer: Pete McCann
> Review Date: 15 June 2009
> IETF LC End Date: 16 June 2009
> IESG Telechat date: unknown 
> 
> Summary: Basically ready, one minor question
> 
> Major issues: none
> 
> Minor issues:
> 
> Section 2:
>setting of in the
> Did you mean:
>setting of the N bit in the
> ?

Yes, thanks; fixed.

> 
> In deprecating this N bit, will there be compatibility problems if an
> implementation sends ICRQ, ICRP, OCRQ, or OCRP with the N bit clear?
> Is it possible that older implementations would treat this as an invalid
> message?

There shouldn't be; as long as an implementation includes the Circuit
Status AVP (because it is a "MUST be present" AVP for those four
messages), it would not be invalid because of the value of the N bit
field.  Note that from its definition in S5.4.5 of RFC3931 at
, it says:

  Otherwise, the New bit SHOULD still be set the first time the L2TP
  session is established after provisioning.

so there is potential room for dealing with not setting it; similar
language exists on the other RFCs being updated ("the New bit indicates
..." or "the New bit SHOULD be set ..."), so there would not be
compatibility problems.

> 
> Nits/editorial comments: none
> 

Hopefully this reply clarifies, thanks again for your review !

-- Carlos.

> 
> 
> ___
> L2tpext mailing list
> l2tp...@ietf.org
> https://www.ietf.org/mailman/listinfo/l2tpext
> 
___
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-ospf-dynamic-hostname-03

[Carlos Pignataro]

Hi Spencer,

Thanks for your review, we've make these changes for the next (post-IETF
LC) revision.

Thanks,

-- Carlos.

On 6/12/2009 3:22 PM, Spencer Dawkins wrote:
> Hi, Carlos,
> 
> Both of your proposed issue resolutions work for me (and I agree about 
> putting the duplicated hostname note in the Security Considerations section, 
> and not in Section 3).
> 
> Thanks,
> 
> Spencer
> 
> - Original Message - 
> From: "Carlos Pignataro" 
> To: "Spencer Dawkins" 
> Cc: "Sanjay Harwani (sharwani)" ; "Subbaiah Venkata" 
> ; "Danny McPherson" ; ; 
> "General Area Review Team" ; "Ross Callon" 
> ; "Acee Lindem" ; "Abhay Roy (akr)" 
> 
> Sent: Friday, June 12, 2009 10:29 AM
> Subject: Re: Gen-ART review of draft-ietf-ospf-dynamic-hostname-03
> 
> 
>> Hi Spencer,
>>
>> Thank you for your review, please see inline.
>>
>> On 6/12/2009 6:24 AM, Spencer Dawkins wrote:
>>> Hi, Sanjay,
>>>
>>> please see inline starting with SD:
>>>
>>> And thanks for a quick response (before I leave for vacation today).
>>>
>>> Spencer
>>>
>>> - Original Message - 
>>> From: "Sanjay Harwani (sharwani)" 
>>> To: "Spencer Dawkins" ; "Subbaiah Venkata"
>>> ; "Danny McPherson" ; "Carlos 
>>> Pignataro
>>> (cpignata)" 
>>> Cc: ; "General Area Review Team" ; "Ross
>>> Callon" ; "Acee Lindem" ; "Abhay 
>>> Roy
>>> (akr)" 
>>> Sent: Thursday, June 11, 2009 11:38 PM
>>> Subject: RE: Gen-ART review of draft-ietf-ospf-dynamic-hostname-03
>>>
>>>
>>> Adding in Carlos who holds the pen for us, Please see inline starting
>>> with SH:
>>>
>>> -Original Message-
>>> From: Spencer Dawkins [mailto:spen...@wonderhamster.org]
>>> Sent: Friday, June 12, 2009 3:55 AM
>>> To: Subbaiah Venkata; Sanjay Harwani (sharwani); Danny McPherson
>>> Cc: i...@ietf.org; General Area Review Team; Ross Callon; Acee Lindem;
>>> Abhay Roy (akr)
>>> Subject: Gen-ART review of draft-ietf-ospf-dynamic-hostname-03
>>>
>>> I have been selected as the General Area Review Team (Gen-ART) reviewer
>>> for this draft (for background on Gen-ART, please see
>>> http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html).
>>>
>>> Please resolve these comments along with any other Last Call comments
>>> you may receive.
>>>
>>> Document: draft-ietf-ospf-dynamic-hostname-03
>>> Reviewer: Spencer Dawkins
>>> Review Date: 2009-06-11
>>> IETF LC End Date: 2009-06-16
>>> IESG Telechat date: (not known)
>>>
>>> Summary: This document is almost ready for publication as a Proposed
>>> Standard. I identified two minor issues listed below.
>>>
>>> 2.  Possible solutions
>>>
>>>Another approach is having a centralized location where the name-to-
>>>Router ID mapping can be kept.  DNS can be used for the same.  A
>>>disadvantage with this centralized solution is that its a single
>>>
>>> Spencer (nit): s/its/it's/
>> Ack -- fixed in the working copy.
>>
>>>point of failure; and although enhanced availability of the central
>>>mapping service can be designed, it may not be able to resolve the
>>>hostname in the event of reachability or network problems.  Also, the
>>>response time can be an issue with the centralized solution, which
>>>can be particularly problematic in times of problem resolution.  If
>>>
>>> Spencer (minor): good point on response times, but I'd also think you'd
>>> point out that looking up attributes on a centralized mapping table is
>>> exactly the wrong thing to do when you're resolving problems with
>>> routing - the centralized resource may not even be reachable.
>>>
>>> SH: I think we already have it covered just above in the same paragraph.
>>> (single point of failure)
>>> 
>>>  A disadvantage with this centralized solution is that its a
>>> single
>>>point of failure; and although enhanced availability of the central
>>>mapping service can be designed, it may not be able to resolve the
>>>hostname in the event of reachability or network problems.
>>> 
>>>
>>> SD: I'll call for my e

Re: [Gen-art] Gen-ART review of draft-ietf-ospf-dynamic-hostname-03

[Carlos Pignataro]

Hi Spencer,

Thank you for your review, please see inline.

On 6/12/2009 6:24 AM, Spencer Dawkins wrote:
> Hi, Sanjay,
> 
> please see inline starting with SD:
> 
> And thanks for a quick response (before I leave for vacation today).
> 
> Spencer
> 
> - Original Message - 
> From: "Sanjay Harwani (sharwani)" 
> To: "Spencer Dawkins" ; "Subbaiah Venkata" 
> ; "Danny McPherson" ; "Carlos Pignataro 
> (cpignata)" 
> Cc: ; "General Area Review Team" ; "Ross 
> Callon" ; "Acee Lindem" ; "Abhay Roy 
> (akr)" 
> Sent: Thursday, June 11, 2009 11:38 PM
> Subject: RE: Gen-ART review of draft-ietf-ospf-dynamic-hostname-03
> 
> 
> Adding in Carlos who holds the pen for us, Please see inline starting
> with SH:
> 
> -Original Message-
> From: Spencer Dawkins [mailto:spen...@wonderhamster.org]
> Sent: Friday, June 12, 2009 3:55 AM
> To: Subbaiah Venkata; Sanjay Harwani (sharwani); Danny McPherson
> Cc: i...@ietf.org; General Area Review Team; Ross Callon; Acee Lindem;
> Abhay Roy (akr)
> Subject: Gen-ART review of draft-ietf-ospf-dynamic-hostname-03
> 
> I have been selected as the General Area Review Team (Gen-ART) reviewer
> for this draft (for background on Gen-ART, please see
> http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html).
> 
> Please resolve these comments along with any other Last Call comments
> you may receive.
> 
> Document: draft-ietf-ospf-dynamic-hostname-03
> Reviewer: Spencer Dawkins
> Review Date: 2009-06-11
> IETF LC End Date: 2009-06-16
> IESG Telechat date: (not known)
> 
> Summary: This document is almost ready for publication as a Proposed
> Standard. I identified two minor issues listed below.
> 
> 2.  Possible solutions
> 
>Another approach is having a centralized location where the name-to-
>Router ID mapping can be kept.  DNS can be used for the same.  A
>disadvantage with this centralized solution is that its a single
> 
> Spencer (nit): s/its/it's/

Ack -- fixed in the working copy.

> 
>point of failure; and although enhanced availability of the central
>mapping service can be designed, it may not be able to resolve the
>hostname in the event of reachability or network problems.  Also, the
>response time can be an issue with the centralized solution, which
>can be particularly problematic in times of problem resolution.  If
> 
> Spencer (minor): good point on response times, but I'd also think you'd
> point out that looking up attributes on a centralized mapping table is
> exactly the wrong thing to do when you're resolving problems with
> routing - the centralized resource may not even be reachable.
> 
> SH: I think we already have it covered just above in the same paragraph.
> (single point of failure)
> 
>  A disadvantage with this centralized solution is that its a
> single
>point of failure; and although enhanced availability of the central
>mapping service can be designed, it may not be able to resolve the
>hostname in the event of reachability or network problems.
> 
> 
> SD: I'll call for my eye exam appointment when they open :-). What I liked 
> about the response time text was that it clearly called out the impact on 
> problem resolution - if it was possible for this to be clearly stated for 
> reachability, that seems helpful to me. If I was suggesting text, it might 
> be something like:
> 
> SD: A disadvantage with this centralized solution is that it's a single 
> point of failure; and although enhanced availability of the central mapping 
> service can be designed, it may not be able to resolve the hostname in the 
> event of reachability or network problems, which can be particularly 
> problematic in times of problem resolution. Also, the response time can be 
> an issue with the centralized solution, which can be equally problematic.
> 

I think this text improves the paragraph. It is a very subtle (surgical)
change, but it highlights and emphasizes the impact on problem
resolution for both reachability and response time. Thanks for the
suggestion.
[Authors: change made in the working copy, let me know if other suggestions]


> 3.  Implementation
> 
>The Dynamic Hostname TLV (see Section 3.1) is OPTIONAL.  Upon receipt
>of the TLV a router may decide to ignore this TLV, or to install the
>symbolic name and Router ID in its hostname mapping table.
> 
> Spencer (minor): I'm suspecting that if this attribute becomes widely
> deployed, network operators would train themselves to read the hostname
> and pay very little attention to the numeric router ID, so I'm won

Re: [Gen-art] [Softwires] Gen-ART review of draft-ietf-softwire-hs-framework-l2tpv2-10

[Carlos Pignataro]

WG,

On 12/22/2008 7:49 PM, black_da...@emc.com said the following:
> After a lengthy private discussion with Carlos, and some
> serious "quality time" spent with RFC 2661 ;-), here's
> where I think the two major issues from my Gen-ART review
> of this draft stand:
> 
> (1) AVP for softwire profile of L2TPv2.  I'm no longer
> convinced that a new AVP is needed, but the specification
> of the profile needs significant clarification and cleanup.

For completeness, I do not think that significant cleanup is needed, but
rather that some localized editorial clarifications of context might
help the reader. In any case, one of the big decisions in this
discussion is that there's no new "softwire AVP", and some fall out is
that S5.1.1.X can use more specific descriptions.

> For example, what happens if a softwire implementation of
> L2TPv2 happens to receive an OCRQ message?

For example, draft-ietf-softwire-hs-framework-l2tpv2 specifies that:

   in the Softwire context, the voluntary tunneling model applies
...
   Since L2TPv2 compulsory tunneling model does
   not apply to Softwires, it should not be requested or honored.
...
   In the Softwire "Hub and Spoke" model, the Softwire Initiator (SI)
   assumes the role of the LAC Client

And more notably:

   No outgoing or analog calls are permitted.


So, if a softwire implementation of L2TPv2 happens to receive an OCRQ
message, it needs to CDN it (as strongly hinted though not explicitly
spelled out; for a versatile and variation-rich protocol as L2TP a this
seems a self-evident exception protocol paths for softwire). The
fall-through protocol definition lies in RFC2661 (the doc says "as
defined in [RFC2661]"), and that scenario is the same as "if a full
RFC2661 implementation of L2TP not configured for outgoing calls
receives an OCRQ message".


> This has also
> turned up a topic that needs to be covered in the Security
> Considerations section - a brief discussion of the security
> consequences of the recommendation not to hide AVPs.

Right, this is one new thing that came up, from looking into the Random
Vector AVP. The document is recommending not to hide AVPs, from the very
original text. But, I think, the document "MAY" allow AVP hiding
(instead of describing the consequences of not hiding).

> 
> (2) RFC 5405 and UDP.  In addition to referencing RFC 5405,
> a recommendation for L2TPv2 use of PMTUD will be added.

We will describe all the changes when we post an updated version of the
document.

Thanks,

--Carlos.

> 
> Thanks,
> --David
> 
> David L. Black, Distinguished Engineer
> EMC Corporation, 176 South St., Hopkinton, MA  01748
> +1 (508) 293-7953 FAX: +1 (508) 293-7786
> black_da...@emc.comMobile: +1 (978) 394-7754
> 
> 

-- 
--Carlos Pignataro, DSE, CISCO.
___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

Re: [Gen-art] Gen-ART review of draft-mammoliti-l2tp-accessline-avp-04

[Carlos Pignataro]

Vijay,

Many thanks for taking the time to review this document ! Please see inline.

On 12/15/2008 10:36 AM, Vijay K. Gurbani said the following:
> I have been selected as the General Area Review Team (Gen-ART)
> reviewer for this draft (for background on Gen-ART, please see
> http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html).
> 
> Please resolve these comments along with any other Last Call comments
> you may receive.
> 
> Document: draft-mammoliti-l2tp-accessline-avp-04.txt
> Reviewer: Vijay K. Gurbani
> Review Date: 2008-12-15
> IETF LC End Date: 2008-12-16
> 
> Summary: The draft is ready for publication as an Informational.

OK, Thanks for the review.

> 
> One nit:
> 
> In S2.2, please consider defining the terms "LAC" and "LNS".
> If these are well understood terms in this domain, then please
> go ahead and disregard this nit, but if that is not the case,
> then a definition will help.

Even if they are well understood terms, we will add these ("LAC", "LNS"
and also "LCCE") to S2.2. This came up also in the Sec-Dir review.

Thanks for the feedback,

--Carlos.

> 
> Thanks,
> 
> - vijay

-- 
--Carlos Pignataro.
Escalation RTP - cisco Systems
___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

Re: [Gen-art] [Softwires] Gen-ART review of draft-ietf-softwire-hs-framework-l2tpv2-10

[Carlos Pignataro]

David,

On 12/12/2008 8:02 PM, black_da...@emc.com said the following:
> Carlos,
> 
> (1) AVP for softwire profile of L2TPv2.
> 
> I can mostly agree with the following:
> 
>> 2. The softwire application does not define any requirement over
> RFC2661
>>(it does not differ, it's only a subset), and thus such signaling
> of
>>the softwire profile would be solely informational.
> 
> If a softwire profile implementation of L2TPv2 talks to a full
> RFC2661 implementation, the latter may be in for a few surprises
> courtesy of the subsetting.

Not really: the subset is on optional AVPs, on sending (i.e., out of the
RFC2661 optional AVPs, these are useful for softwire with the following
usage, don't send the rest); and additional guidance on how to use the
mandatory AVPs in the softwire context (i.e., for these RFC2661
mandatory AVPs, these values make sense for softwire). A full RFC2661
implementation should not choke.

> 
> Would it be reasonable to define an informational AVP that the
> softwire profile implementation would send solely to inform its
> peer that the other end of the session is behaving according to
> the software profile?

I think the above + reason #1, minimize protocol changes to only when
it's necessary, weights much more given that there are informational
AVPs (orthogonal to softwire) that are defined for logging in a more
generic way and can be used to say "softwire here". There's also an
expectation that an end knows what it's trying to connect to as well. And...

> 
> If the RFC2661 implementation logs that informational AVP (at
> least if debugging is turned on), that might be helpful to someone
> trying to figure out what's going on if a softwire profile
> implementation of L2TPv2 tries to talk to a full RFC2661
> implementation.

... the usage would be only for logging/debugging/troubleshooting
purposes and not for protocol states/decisions.

If you think it helps, and it's not redundant, we can add a paragraph
saying that the use of existing informational AVPs (or more generically
methods) used for logging is not prevented in the softwire context.

> 
> (2) RFC 5405 and UDP.
> 
>> We don't have strong feelings here one way of another, what do others
>> think? Maybe the middle ground is to cite RFC 5405 as an Informational
>> reference, just saying what you said (that "Section 3.1.3 of RFC 5405
>> specifies that for this case no additional congestion control is
>> required" followed (maybe) by ", and other considerations may apply" -
>> not MAY apply)?
> 
> The version of that text with "other considerations may apply"
> for me. The one other possibly relevant topic that immediately
> comes to mind is the MTU.  Section 5.2.1 of your draft already
> covers the MTU reduction effects of the tunnel headers, and
> that's probably enough. 

OK.

> Section 3.2 of RFC 5405 (on Message Size)
> would apply to UDP over an IP softwire, not the UDP encapsulation
> within the softwire (the latter manifests as the IP MTU of the
> softwire "link").

OK, a pointer to Section 8.1 of RFC2661 + Section 3.2 of RFC 5405, and
suggest the use of PMTUD?

Perhaps a new Section 5.1.4 with "Additional L2TPv2 Considerations",
describing these 2 issues ((1) and (2))? Or maybe (1), if included, fits
better in Section 9 (since the logging can happen outside l2tp as well)?

> 
> The description of what is to be done about the remaining minor
> items is fine with me.

OK.

Thanks,

--Carlos.

> 
> Thanks,
> --David
>  
> 
>> -Original Message-
>> From: gen-art-boun...@ietf.org 
>> [mailto:gen-art-boun...@ietf.org] On Behalf Of Carlos Pignataro
>> Sent: Friday, December 12, 2008 9:43 AM
>> To: Black, David
>> Cc: softwi...@ietf.org; W. Mark Townsley; gen-art@ietf.org; Jari Arkko
>> Subject: Re: [Gen-art] [Softwires] Gen-ART reviewof 
>> draft-ietf-softwire-hs-framework-l2tpv2-10
>>
>> Alain, Mark,
>>
>> We are planning on posting a new revision -11 when we close on these.
>>
>> David,
>>
>> Thanks again for the review, please see inline.
>>
>> On 12/10/2008 2:03 PM, Carlos Pignataro said the following:
>>> David,
>>>
>>> Thanks much for taking the time to read the draft and for 
>> providing this
>>> feedback! This is an Ack, we'll reply later, with answers/text to
>>> address these open issues.
>>>
>>> Thanks,
>>>
>>> --Carlos.
>>>
>>> On 12/10/2008 11:47 AM, black_da...@emc.com said the following:
>>>> I have been selected as the General Area Review Team (Gen-ART) 
>>>> rev

Re: [Gen-art] [Softwires] Gen-ART review of draft-ietf-softwire-hs-framework-l2tpv2-10

[Carlos Pignataro]

Alain, Mark,

We are planning on posting a new revision -11 when we close on these.

David,

Thanks again for the review, please see inline.

On 12/10/2008 2:03 PM, Carlos Pignataro said the following:
> David,
> 
> Thanks much for taking the time to read the draft and for providing this
> feedback! This is an Ack, we'll reply later, with answers/text to
> address these open issues.
> 
> Thanks,
> 
> --Carlos.
> 
> On 12/10/2008 11:47 AM, black_da...@emc.com said the following:
>> I have been selected as the General Area Review Team (Gen-ART) 
>> reviewer for this draft (for background on Gen-ART, please see 
>> http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html).
>> Please resolve these comments along with any other Last Call
>> comments  you may receive.
>>
>> Document: draft-ietf-softwire-hs-framework-l2tpv2-10
>> Reviewer: David L. Black
>> Review Date: December 10, 2008
>> IETF LC End Date: December 15, 2008
>>
>> Summary:
>> This draft is on the right track, but has open issues, described
>> in the review.
>>
>> Comments:
>>
>> The draft is well-written, with a lot of details that will be
>> valuable to implementers.  I have two open issues:
>>
>> (1) Section 5.1 of this draft is clearly defining a softwire
>> profile of L2TPv2 in that it states extensive requirements
>> on AVP usage (and AVP contents in some cases) for softwires.
>> Use of this profile is not explicitly signaled - the
>> expectation is that both the SI and SC will be implemented
>> in accordance with this draft, and won't try to communicate
>> with L2TPv2 implementations that aren't using this profile.
>> As the requirements of this softwire profile appear to differ
>> from RFC 2661, defining an AVP to signal use of this profile
>> seems like a good idea (its use should be required).

We think we shouldn't define a new "Softwire Profile AVP", for a number
of reasons:
1. From the Softwire Problem Statement [RFC4925], there is an emphasis
   in using existing protocols and extending "where necessary" (see [1]
   at the bottom). This document does not make any protocol extensions
   to standards L2TPv2, so this is best case from a requirements
   standpoint, and to change that there would need to be a significant
   benefit.
2. The softwire application does not define any requirement over RFC2661
   (it does not differ, it's only a subset), and thus such signaling of
   the softwire profile would be solely informational. OTOH, if
   enforced, it could potentially limit interop.
3. We don;t think that an additional AVP would provide benefits in
   terms of interoperability. The requirement in section 5.1.1.3 to
   silently ignore unknown or irrelevant AVPs seems enough. That allows
   for interoperability of different versions of softwire that might use
   extra AVPs in the future.

>>
>> (2) This is more of a minor annoyance than an open issue, but
>> it does need attention.  This draft uses UDP as part of an
>> IP-in-IP tunnel, so the UDP guidelines in RFC 5405 apply.
>> Note that Section 3.1.3 of RFC 5405 indicates that no
>> additional congestion control is required for this scenario
>> beyond what is already done for the IP traffic carried through
>> the tunnel.  That should be noted in this draft, and RFC 5405
>> should be scanned for any other considerations that may apply
>> to this draft.

The softwire scenarios carry IP, and like you said, fall under the
Section 3.1.3 of RFC 5405 [2], which is a noop for the softwire case
from a congestion control standpoint. On one hand side, it feels odd and
non-causal to add requirements (spec'd after L2TP) for a protocol used
as-is from when defined in RFC2661. This draft is not defining the
tunneling protocol. OTOH, those are good guidelines and would not hurt.

We don't have strong feelings here one way of another, what do others
think? Maybe the middle ground is to cite RFC 5405 as an Informational
reference, just saying what you said (that "Section 3.1.3 of RFC 5405
specifies that for this case no additional congestion control is
required" followed (maybe) by ", and other considerations may apply" -
not MAY apply)?

How were you suggesting we point to RFC5405, and where specifically in
the text?


>>
>> Everything else I found is relatively minor:
>> - Please add CPE and LNS to the abbreviations section.

Done.

>> - Most of the text after the figure in each of Sections 3.1.1
>>  through 3.1.4 is common.  Consider factoring it out into
>>  one location.  Ditto for 3.2.1 to 3.2.4.  It's fine to
>>  not do this if the result would be difficult to follow.

The common factors are (most

Re: [Gen-art] Gen-ART review of draft-ietf-softwire-hs-framework-l2tpv2-10

[Carlos Pignataro]

David,

Thanks much for taking the time to read the draft and for providing this
feedback! This is an Ack, we'll reply later, with answers/text to
address these open issues.

Thanks,

--Carlos.

On 12/10/2008 11:47 AM, [EMAIL PROTECTED] said the following:
> I have been selected as the General Area Review Team (Gen-ART) 
> reviewer for this draft (for background on Gen-ART, please see 
> http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html).
> Please resolve these comments along with any other Last Call
> comments  you may receive.
> 
> Document: draft-ietf-softwire-hs-framework-l2tpv2-10
> Reviewer: David L. Black
> Review Date: December 10, 2008
> IETF LC End Date: December 15, 2008
> 
> Summary:
> This draft is on the right track, but has open issues, described
> in the review.
> 
> Comments:
> 
> The draft is well-written, with a lot of details that will be
> valuable to implementers.  I have two open issues:
> 
> (1) Section 5.1 of this draft is clearly defining a softwire
> profile of L2TPv2 in that it states extensive requirements
> on AVP usage (and AVP contents in some cases) for softwires.
> Use of this profile is not explicitly signaled - the
> expectation is that both the SI and SC will be implemented
> in accordance with this draft, and won't try to communicate
> with L2TPv2 implementations that aren't using this profile.
> As the requirements of this softwire profile appear to differ
> from RFC 2661, defining an AVP to signal use of this profile
> seems like a good idea (its use should be required).
> 
> (2) This is more of a minor annoyance than an open issue, but
> it does need attention.  This draft uses UDP as part of an
> IP-in-IP tunnel, so the UDP guidelines in RFC 5405 apply.
> Note that Section 3.1.3 of RFC 5405 indicates that no
> additional congestion control is required for this scenario
> beyond what is already done for the IP traffic carried through
> the tunnel.  That should be noted in this draft, and RFC 5405
> should be scanned for any other considerations that may apply
> to this draft.
> 
> Everything else I found is relatively minor:
> - Please add CPE and LNS to the abbreviations section.
> - Most of the text after the figure in each of Sections 3.1.1
>   through 3.1.4 is common.  Consider factoring it out into
>   one location.  Ditto for 3.2.1 to 3.2.4.  It's fine to
>   not do this if the result would be difficult to follow.
> - In Section 5.1.1.3, please clarify that the "SHOULD NOT send"
>   requirement applies only to AVPs not covered in sections
>   5.1.1, 5.1.1.1 and 5.1.1.2 .
> - I found a number of lower case instances of "must", "should"
>   and "may" that are candidates for upper case (i.e.,
>   RFC 2119 usage).  Please check all of these and upper case
>   as appropriate.
> - Please expand the ULA acronym on its first use in Section
>   6.1.1 .
> 
> Thanks,
> --David
> 
> David L. Black, Distinguished Engineer
> EMC Corporation, 176 South St., Hopkinton, MA  01748
> +1 (508) 293-7953 FAX: +1 (508) 293-7786
> [EMAIL PROTECTED]Mobile: +1 (978) 394-7754
> 
> 

-- 
--Carlos Pignataro.
Escalation RTP - cisco Systems
___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

[Gen-art] Re: Gen-ART review of draft-cheshire-ipv4-acd-05.txt

[Carlos Pignataro]

 the worst case by no more than a factor of two.  In the
>traditional usage of ARP, a unicast ARP Reply only occurs in response
>to a broadcast ARP Request, so sending these via broadcast instead
>means that we generate at most one broadcast Reply in response to
>each existing broadcast Request.  On many networks, ARP traffic is
>such an insignificant proportion of the total traffic that doubling
>it makes no practical difference.  However, this may not be true of
>all networks, so broadcast ARP Replies SHOULD NOT be used
> 
> Spencer: slightly confused about why SHOULD NOT, if this is not a problem in 
> most cases. Is this stronger (or broader) than it needs to be? Is this an 
> implicit recommendation for "if an implementation supports broadcast ARP 
> Replies, it SHOULD also include a knob restricting operation to unicast ARP 
> Replies, and the default setting SHOULD be 'unicast'"?
> 
>universally.  Broadcast ARP Replies should be used where the benefit
>of faster conflict detection outweighs the cost of increased
>broadcast traffic and increased packet processing load on the
>participant network hosts.
> 
> 4. Historical Note
> 
> ...
> 
>The problems caused by this ineffective duplicate address detection
>technique are illustrated by the fact that (as of August 2004)
>the top Google search results for the phrase "Gratuitous ARP" are
>articles describing how to disable it.
> 
> Spencer (nit): this isn't true (three years later), but s/are/include/ IS 
> true ...
> 
>However, implementers of IPv4 Address Conflict Detection should be
>aware that, as of this writing, Gratuitous ARP is still widely
> 
> Spencer: still true in 2007? I assume so, but don't know.
> 
>deployed.  The steps described in Sections 2.1 and 2.4 of this
>document help make a host robust against misconfiguration and address
>conflicts, even when the other host is *not* playing by the same
>rules. 
> 
> 
> 
> ___
> Ietf mailing list
> [EMAIL PROTECTED]
> https://www1.ietf.org/mailman/listinfo/ietf
> 

-- 
--Carlos Pignataro.
Escalation RTP - cisco Systems


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

[Gen-art] Re: Gen-ART LC Review of draft-ietf-mpls-over-l2tpv3-01.txt

[Carlos Pignataro]

Hi Spencer,

Thanks again, please see inline.

On 9/25/2006 2:59 PM, Spencer Dawkins allegedly said the following:
> Hi, Carlos,
> 
> Thanks for the quick feedback. I think we can finish this up today.
> 
> Please see inline.
> 
> Spencer
> 
> 
>> Spencer,
>>
>> Thank you for your review and comments. Please see inline.
>>
>> On 9/22/2006 3:37 PM, Spencer Dawkins allegedly said the following:
>>> I have been selected as the General Area Review Team (Gen-ART) reviewer 
>>> for
>>> this draft (for background on Gen-ART, please see
>>> http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html).
>>>
>>> Please resolve these comments along with any other Last Call comments you
>>> may receive.
>>>
>>> Document: draft-ietf-mpls-over-l2tpv3-01.txt
>>> Reviewer: Spencer Dawkins
>>> Review Date:  2006-09-22
>>> IETF LC Date: 2006-10-04
>>> IESG Telechat date:
>>> Summary: This draft is almost ready for publication as a Proposed 
>>> Standard.
>>>
>>>The optional L2-Specific-Sublayer defined in [RFC3931] is generally
>>>
>>> Spencer (editorial): I know this term is used in RFC 3931, but wish it 
>>> was
>>> something like "-Sublayer header" or "-Sublayer bits", just for 
>>> readability.
>> I'd like to use the [RFC3931] term, "L2-Specific Sublayer" (without the
>> second dash). I'll ensure this is used consistently throughout the doc.
> 
> This works for me. I wish "Sublayer" sounded more like a header field than 
> part of a protocol stack, but the community may already be accustomed to 
> this usage.

OK. I see your point; but I believe that the common usage of the term
carries an implicit "header" in its meaning though.

> 
>>>not present for MPLS over L2TPv3.
>>>
>>> 4. Applicability
>>>
>>>MPLS over L2TPv3 may be favorable compared to [RFC4023], if:
>>>
>>> Spencer: I'm not sure what "may be favorable compared to" is saying. Is 
>>> this
>>> "may have advantages compared to"?
>> OK, "may be advantageous compared to" (was using favorable as synonym to
>> advantageous, or having advantages).
> 
> This is fine, and helps me to parse the next sentence.

OK.

> 
>>>   Two routers are "adjacent" over an L2TPv3 tunnel that exists for
>>>   some reason outside the scope of this document, and those two
>>>   routers need to send MPLS packets over that adjacency.
>>>
>>> Spencer: I'm not sure what this sentence is saying, and can't parse it 
>>> well
>>> enough to rephrase - sorry!
>> It's trying to say that one advantage is when there is already a
>> pre-existing L2TPv3 tunnel between two routers that can be used to send
>> MPLS packets over it.
> 
> OK, I think I understand now. Suggest "Two routers are already "adjacent" 
> over an L2TPv3 tunnel established for some other reason, and wish to 
> exchange MPLS packets over that adjacency."

That works, thanks for the suggestion.

> 
>>> 5.1 In the Absence of IPsec
>>>
>>>However, when the tunnel head and the tunnel tail are not in the same
>>>administrative domain, this may become difficult, and filtering based
>>>on the destination address can even become impossible if the packets
>>>must traverse the public Internet.
>>>
>>> Spencer: I'm not sure I understand the point being made here. Why does
>>> traversing the public internet make this impossible, if crossing
>>> administrative domain boundaries makes it difficult?
>> Note that a design consideration for this section is to be inline with
>> RFC4023, so there is a desire to stay consistent in this sentence. See
>> second para in http://ietf-tools.sth.netnod.se/html/rfc4023#section-8.2
> 
> I understand the design consideration (and see that the same paragraph 
> appears in RFC 4023), I was saying that the text didn't explain why 
> destination filtering was difficult/impossible. It may be that I'm the only 
> person who doesn't know why - in that case, the text is fine :-)
> 

OK, will keep the text as is.

Many thanks for your review !

--Carlos.

> Thanks,
> 
> Spencer 
> 

-- 
--Carlos Pignataro.
Escalation RTP - cisco Systems

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

[Gen-art] Re: Gen-ART LC Review of draft-ietf-mpls-over-l2tpv3-01.txt

[Carlos Pignataro]

cryption.
>However, when used with a sufficiently random 64-bit value which is
>kept secret from a hacker, the L2TPv3 Cookie may be used as a simple
> 
> Spencer: is this "kept secret from an off-path attacker"?

Yes, thanks.

> 
>yet effective packet source authentication check which is quite
>resistant to brute force packet spoofing attacks. It also alleviates
>the need to rely solely on filter lists based on a list of valid
>source IP addresses, and thwarts attacks which could benefit by
>spoofing a permitted source IP address.  The L2TPv3 Cookie provides a
>means of validating the currently assigned Session ID on the packet
>flow, providing context protection, and may be deemed complimentary
>to securing the tunnel utilizing IPsec.  In the absence of
>cryptographic security on the data plane (such as that provided by
>IPsec), the L2TPv3 Cookie provides a simple method of validating the
>Session ID lookup performed on each L2TPv3 packet. If the Cookie is
>sufficiently random and remains unknown to an attacker (that is, the
>attacker has no way to predict Cookie values or monitor traffic
>between PEs) then the Cookie provides an additional measure of
>protection against malicious spoofed packets inserted at the PE over
>and above that of typical IP address and port ACLs.
> 
> 5.3 Securing the Tunnel with IPsec
> 
>Key distribution may be done either manually or automatically by
>means of IKE [RFC2409].  Manual keying MUST be supported.  If
> 
> Spencer: Is the limitation to IKEv1 intentional? This text seems to preclude
> use of IKEv2 (RFC 4306).

It was not intended to preclude IKEv2, we'll add it.

Thanks again,

--Carlos.

> 
>automatic keying is implemented, IKE in main mode with preshared keys
>MUST be supported.  A particular application may escalate this
>requirement and request implementation of automatic keying.  Manual
>key distribution is much simpler, but also less scalable, than
>automatic key distribution. If replay protection is regarded as
>necessary for a particular tunnel, automatic key distribution should
>be configured.
> 

-- 
--Carlos Pignataro.
Escalation RTP - cisco Systems

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