[Gen-art] Gen-ART review of draft-ietf-ccamp-additional-signal-type-g709v3-04

[Ronald Bonica]

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

Document:  
draft-ietf-ccamp-additional-signal-type-g709v3-04
Reviewer:Ron Bonica
Review Date:  2016-05-31
IETF LC End Date:  2016-06-08
IETF Telechat Date:  2016-06-08

Summary: RFC 4328 and RFC 7139 provide Resource ReserVation 
Protocol-Traffic Engineering (RSVP-TE) signaling extensions to control the full 
set
of Optical Transport Network (OTN) features. However, these specifications do 
not cover the additional Optical channel Data
Unit (ODU) containers defined in G.Sup43 (ODU1e, ODU3e1 and ODU3e2). This 
document defines new signal types for these additional containers.

Major Issues: I think that we are ready for publication. But can someone 
confirm that it is OK to update the registry from an INFORMATIONAL RFC? I think 
that it is, because the registry policy is:

Standards Action for Standards Track documents, Specification Required  for 
other documents

Minor Issues: None

Editorial Issues: None

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

[Gen-art] Gen-ART review for draft-ietf-aqm-pie

[Ronald Bonica]

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

Document:  draft-ietf-aqm-pie
Reviewer:Ron Bonica
Review Date:  2016-05-19
IETF LC End Date:  2016-05-04
IETF Telechat Date:  2016-05-19

Summary:  This document is ready for publication.

It appears to be a reasonable experiment with adaptive queuing. (Full 
disclosure: I am not an expert in this area.)

Major Issues: None

Minor Issues: None

Editorial Issues: None

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

[Gen-art] Gen-ART Review of draft-ietf-netext-logical-interface-support

[Ronald Bonica]

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

Document:  
draft-ietf-netext-logical-interface-support-12
Reviewer:Ron Bonica
Review Date:  2016-01-30
IETF LC End Date:  2016-02-05
IETF Telechat Date:  TBD

Summary:  This document is ready for publication

Major Issues: None

Minor Issues: None

Editorial Issues: None


Ron Bonica


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

Re: [Gen-art] Gen-ART review of

[Ronald Bonica]

Folks,

The authors of this draft have informed me this document is required by the wg 
charter. So, I withdraw any criticisms about this document's limited scope. The 
scope was dictated by the charter.

  Ron


> -Original Message-
> From: Ronald Bonica
> Sent: Tuesday, December 15, 2015 4:01 PM
> To: IETF Gen-ART <gen-art@ietf.org>; 'draft-ietf-pals-congcons@ietf.org'
> <draft-ietf-pals-congcons@ietf.org>
> Subject: Gen-ART review of
> 
> I am the assigned Gen-ART reviewer for this draft. For background on Gen-
> ART, please see the FAQ at
> <http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>
> 
> Document:  draft-ietf-pals-congcons-01
> Reviewer:Ron Bonica
> Review Date:  2015-12-15
> IETF LC End Date:  2015-12-15
> IETF Telechat Date:  TBD
> 
> Summary:  This document is ready for publication
> 
> In summary, draft-ietf-congcons-01:
> 
> - applies only to pseudowires that run over something other than MPLS (e.g.,
> GRE)
> - concludes that no additional mechanisms are needed for elastic
> pseudowires
> - concludes that an inelastic pseudowire MAY shutdown when it experiences
> higher-than-acceptable loss, latency or jitter
> - observes that that for TDM PWs, as loss rate increases, higher-than-
> acceptable loss generally occurs before the fixed-rate TDM PW could cause
> serious problems for competing congestion-responsive traffic
> - Therefore, no additional mechanisms are needed for inelastic pseudowires,
> either
> 
> I see nothing objectionable in the draft. However, its scope is extremely
> limited and it conclusions are not earthshattering. Nonetheless, the work is
> sound and deserves publication.
> 
> Major Issues: None
> 
> Minor Issues: None
> 
> Editorial Issues:
> 
> Ron Bonica
> 

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

[Gen-art] Gen-ART review of

[Ronald Bonica]

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

Document:  draft-ietf-pals-congcons-01
Reviewer:Ron Bonica
Review Date:  2015-12-15
IETF LC End Date:  2015-12-15
IETF Telechat Date:  TBD

Summary:  This document is ready for publication

In summary, draft-ietf-congcons-01:

- applies only to pseudowires that run over something other than MPLS (e.g., 
GRE)
- concludes that no additional mechanisms are needed for elastic pseudowires
- concludes that an inelastic pseudowire MAY shutdown when it experiences 
higher-than-acceptable loss, latency or jitter
- observes that that for TDM PWs, as loss rate increases, 
higher-than-acceptable loss generally occurs before the fixed-rate TDM PW could 
cause serious problems for competing congestion-responsive traffic
- Therefore, no additional mechanisms are needed for inelastic pseudowires, 
either

I see nothing objectionable in the draft. However, its scope is extremely 
limited and it conclusions are not earthshattering. Nonetheless, the work is 
sound and deserves publication.

Major Issues: None

Minor Issues: None

Editorial Issues: 

Ron Bonica


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

[Gen-art] Gen-ART review of draft-ietf-lwig-ikev2-minimal

[Ronald Bonica]

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

Document:  draft-ietf-lwig-ikev2-minimal-04
Reviewer:Ron Bonica
Review Date:  2015-10-04
IETF LC End Date:  2015-10-02
IETF Telechat Date:  TBD

Summary:  This document is ready for publication

Major Issues: None

Minor Issues: None

Editorial Issues: The Author Address Section is misplaced. It should come 
before the Appendix. The RFC Editor can probably fix that.

Ron Bonica

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

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

[Ronald Bonica]

Russ,

Agree on both points. I have:

- removed the word "unique"
- moved Section 6 to an appendix

Thanks for the review.

   Ron


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

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

Re: [Gen-art] Gen-ART review of draft-ietf-conex-tcp-modifications

[Ronald Bonica]

Suresh,

You are absolutely right. We have two possible solutions, an HBH Option and a 
Destination Option.  Both solutions severely limit CONEX deployability.

Since my comment is more about draft-ietf-conex-destopt than it is about 
draft-ietf-conex-tcp-modifications, I think that we can let 
draft-ietf-conex-tcp-modifications go forward, as is.

Before draft-ietf-conex-tcp-modifications comes up for last call, we might want 
to augment Section 5, explaining why both solutions limit severely limit CONEX 
deployability. Since all of the CONEX documents are EXPERIMENTAL, that caveat 
shouldn't be an impediment to publication.

We will need to address the problem before the CONEX documents become PROPOSED 
STANDARD. But we can cross that bridge when we get to it.


  Ron




> -Original Message-
> From: Suresh Krishnan [mailto:suresh.krish...@ericsson.com]
> Sent: Tuesday, September 08, 2015 2:47 PM
> To: Ronald Bonica <rbon...@juniper.net>; gen-art@ietf.org
> Cc: draft-ietf-conex-tcp-modifications@tools.ietf.org
> Subject: Re: [Gen-art] Gen-ART review of draft-ietf-conex-tcp-modifications
> 
> Hi Ron,
>Thanks for your review. Please find comments inline.
> 
> On 09/08/2015 12:20 PM, Ronald Bonica 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>
> >
> > Document:  
> > draft-ietf-conex-tcp-modifications-09
> > Reviewer:Ron Bonica
> > Review Date:  2015-09-07
> > IETF LC End Date:  2015-08-31
> > IETF Telechat Date:  2015-10-01
> >
> > Summary:  This document will be ready for publication as soon as the
> major issue (below) below is addressed.
> >
> > Major Issues:
> >
> > This document contains a normative reference to draft-ietf-conex-destopt-
> 09. The normative reference is appropriate, because this document doesn't
> work at all unless the concepts described in draft-ietf-conex-destopt-09
> work.
> >
> > I am concerned about draft-ietf-conex-destopt-09. It uses an IPv6
> Destination Option to signal CONEX state to intermediate routers. However,
> according to RFC 2460:
> >
> > "With one exception, extension headers are not examined or processed
> > by any node along a packet's delivery path, until the packet reaches
> > the node (or each of the set of nodes, in the case of multicast)
> > identified in the Destination Address field of the IPv6 header."
> >
> > The exception to which RFC 2460 refers is the Hop-by-hop Extension
> Header. Intermediate routers don't examine Destination Options.
> >
> > Section 5 of draft-ietf-conex-destopt-09 attempts to address this issue, but
> I am not sure that the argument is acceptable.
> 
> I think we can discuss this further but in my view there are no good solutions
> to this problem. There are two probable alternatives here
> 
> Hop-by-hop options: This is arguably the right way to define information that
> is inspected on intermediate nodes. But using this implies that there is a 
> huge
> performance penalty for conex packets that hit conex unaware routers
> (basically being punted into the slow path in the best case, being dropped at
> worst). RFC7045 section 2.2 talks about this explicitly but this problem has
> been known for much longer. This will break requirement R-3.
> 
> Destination options: Intended for the destination of the packet, but capable
> of being read at *consenting* conex-aware network nodes. Does not affect
> nodes that are conex unaware. This is no different than a router that looks at
> a TCP port for an enforcing an ACL, right?
> 
> Let me know what you think. (Especially, we would be grateful if you think
> there is a better solution we ought to be considering that would meet the
> requirements)
> 
> Regards
> Suresh
> 

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

[Gen-art] Gen-ART review of draft-ietf-conex-tcp-modifications

[Ronald Bonica]

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

Document:  
draft-ietf-conex-tcp-modifications-09
Reviewer:Ron Bonica
Review Date:  2015-09-07
IETF LC End Date:  2015-08-31
IETF Telechat Date:  2015-10-01

Summary:  This document will be ready for publication as soon as the 
major issue (below) below is addressed.

Major Issues:

This document contains a normative reference to draft-ietf-conex-destopt-09. 
The normative reference is appropriate, because this document doesn't work at 
all unless the concepts described in draft-ietf-conex-destopt-09 work.

I am concerned about draft-ietf-conex-destopt-09. It uses an IPv6 Destination 
Option to signal CONEX state to intermediate routers. However, according to RFC 
2460:

   "With one exception, extension headers are not examined or processed
   by any node along a packet's delivery path, until the packet reaches
   the node (or each of the set of nodes, in the case of multicast)
   identified in the Destination Address field of the IPv6 header."

The exception to which RFC 2460 refers is the Hop-by-hop Extension Header. 
Intermediate routers don't examine Destination Options.

Section 5 of draft-ietf-conex-destopt-09 attempts to address this issue, but I 
am not sure that the argument is acceptable. 

Minor Issues: None

Editorial Issues:






Ron Bonica

___
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-intarea-gre-ipv6-10

[Ronald Bonica]

Meral,

Thanks for the careful review. All comments accepted.

I will spin a new version before the draft goes to IESG Review.

   Ron

From: Meral Shirazipour [mailto:meral.shirazip...@ericsson.com]
Sent: Tuesday, July 07, 2015 9:02 PM
To: draft-ietf-intarea-gre-ipv6@tools.ietf.org; gen-art@ietf.org
Subject: Gen-ART Last Call review of draft-ietf-intarea-gre-ipv6-10

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

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

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


Summary:
This draft is ready to be published as Standards Track RFC, some editorial 
comments below.

Major issues:

Minor issues:

Nits/editorial comments:
-[Page 3], Section 2.1, The GRE ingress node SHOULD set the Checksum Present 
field to zero.
-It would be clearer to say Checksum Present field in the GRE Header

-[Page 4], Section 2.1, As per RFC 2784, the GRE egress... suggestion add 
section As per RFC 2784 Section 2.2, the GRE...

-[Page 4], Section 3 title, 3.  IPv6 As GRE Payload suggestion small 
a 3.  IPv6 as GRE Payload

-[Page 5], last sentence missing . :  GRE egress

-[Page 6], Section 4 title, 4.  IPv6 As GRE Delivery Protocol suggestion 
small a 4.  IPv6 as GRE Delivery Protocol

-[Page 7], Section 4.3
This section was not clear to me, but I don't have any suggestion. I.e. by 
cannot fragment the IPv6 delivery header, do we mean delivery header and what 
comes after (GRE header and Payload)?
Do we have to be specific or can we just say does not support fragmentation?

-[Page 7], Section 6, More generically,..---suggestion More generally, ...


Best Regards,
Meral
---
Meral Shirazipour
Ericsson
Research
www.ericsson.comhttp://www.ericsson.com
___
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-6man-oversized-header-chain-08

[Ronald Bonica]

Hi Jari,

We would be glad to spin a new version addressing the minor issues. We could do 
it either before or during AUTH48, as you please.

  Ron


 -Original Message-
 From: Jari Arkko [mailto:jari.ar...@piuha.net]
 Sent: Thursday, November 21, 2013 6:59 AM
 To: Peter Yee; Fernando Gont; Brian Haberman
 Cc: draft-ietf-6man-oversized-header-chain@tools.ietf.org; gen-
 a...@ietf.org Team (gen-art@ietf.org)
 Subject: Re: Gen-ART Telechat review of draft-ietf-6man-oversized-
 header-chain-08
 
 Not sure this mail made it to the appropriate parties (Peter reported
 some e-mail issue with the list). However, many thanks for the review,
 Peter, appreciated!
 
 I do agree with the minor issue that Peter raises and the suggested
 text from Fernando. I don't see a new document revision yet, however. I
 assume you Fernando and Brian have the token to ensure that the
 resolution and the resolutions for the nits gets into the document
 before it is shipped to the RFC Editor.
 
 Thanks again, and thank you for writing this document.
 
 Jari
 
  -Original Message-
  From: Peter Yee [mailto:pe...@akayla.com]
  Sent: Monday, November 18, 2013 10:07 AM
  To: 'draft-ietf-6man-oversized-header-chain@tools.ietf.org'
  Cc: 'gen-art@ietf.org'; 'i...@ietf.org list'
  Subject: Gen-ART Telechat review of
  draft-ietf-6man-oversized-header-chain-08
 
  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-6man-oversized-header-chain-08
  Reviewer: Peter Yee
  Review Date: Oct-16-2013 (minor updates: Nov-18-2013) IETF LC End
  Date: Oct-16-2013 IESG Telechat date: Nov-21-2013
 
  Summary: This draft is almost ready for publication as a proposed
  standard but has open issues, described in the review.
  [Ready with issues]
 
  This draft attempts to overcome a potential problem caused by the
  fragmentation of IPv6 header chains by limiting such chains to
 fitting
  within the first fragment.  This permits stateless packet filtering
  firewalls to make an appropriate decision based on a single fragment
  rather than having to rely on incomplete information that might be
  present in a first fragment if the header were split across more than
  one fragment.
 
  Major issues: None
 
  Minor issues:
 
  Page 10, 1st paragraph: the term improperly-fragmented is used.
 Are
  these truly improperly-fragmented packets or simply ones that are
  unfriendly to stateless packet filtering?  It seems more like the
  lengthy headers were within spec to date and are now being prohibited
  to solve a specific problem.
 
  The suggested replacement text from the co-author, This document
  describes how undesirably-fragmented packets can prevent traditional
  stateless packet filtering works for me since the document does then
  explain the issues that make up undesirable fragmentation, if not
  precisely using that term.
 
  Nits:
 
  General: use a comma after the terms e.g. or i.e. throughout the
  document.  Usage is inconsistent.   Traditional usage is to add a
 comma
  after these Latin abbreviations.
 
  Page 3, 3rd paragraph: insert the between from and IPv6.  I
  understand that this item has already been dealt with and should
  appear in a revision of the document before publication.
 
  Page 8, 1st paragraph: replace a with an before IPv6 datagram.
  This comment has also been dealt with but I'm leaving it and the rest
  of the resolved comments in this message since a revised draft isn't
  available at this time.
 
  Page 8, 2nd paragraph: the parenthetical example does not appear to
 be
  a good match for the preceding text.  It is written as a mechanism
  that allows the possible maintenance of the status quo rather than
  giving an example of how the preceding SHOULD might be implemented.
  E.g., indicates an example of something.  The text leading up to the
  parenthetical example is  A host that receives a first-fragment that
  does not satisfy the above-stated requirement SHOULD discard the
  packet.  The parenthetical statement then reads (e.g., including  a
  configuration option that allows such fragments to be accepted for
  backwards compatibility).  So the text is the parenthetical example
  is not an example of a host discarding a first-fragment that fails to
  meet the requirements, it's a statement of something else the host
  might want to do in cases where backwards compatibility is desired.
  In other words, it's sort of the opposite of the clause that
 proceeded
  it.
 
  The co-author has indicated that the remaining comments have been
  addressed, so again they only appear for the record.
 
  Page 8, paragraph 3, 1st sentence: change requirements to
  requirement.  Only one requirement was given and that was 

Re: [Gen-art] Gen-ART review of draft-bonica-special-purpose-03

[Ronald Bonica]

Hi Dan,

Response inline.

 -Original Message-
 From: Romascanu, Dan (Dan) [mailto:droma...@avaya.com]
 Sent: Thursday, December 20, 2012 12:41 PM
 To: gen-art@ietf.org
 Cc: Ronald Bonica; Ralph Droms (rdroms)
 Subject: Gen-ART review of draft-bonica-special-purpose-03
 
 
 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-bonica-special-purpose-03
 Reviewer: Dan Romascanu
 Review Date: 12/20/12
 IETF LC End Date: 01/02/13
 IESG Telechat date: 01/10/13
 
 Summary:
 
 This is a well written, clear, and aparently simple document. It
 instructs IANA to restructure its IPv4 and IPv6 Special-Purpose Address
 Registries, updates the RFCs that define the current structure of the
 IPv4 and IPv6 Special-Purpose Address Registries, and obsoletes the
 RFCs that currently document the Special-Use IPv4 and IPv6 addresses.
 During the IETF Last Call one major issue was raised, and this issue
 needs to be clarified before the IESG decides how to proceed with this
 document. A small number of minor issues and editorial comments can be
 easily resolved.

Thanks!

 
 
 Major issues:
 
 Geoff Hunt pointed during the IETF Last Call that this document
 actually deals with two different categories of addresses:
 - address reservations for which the functionality should be included
 in the IP stacks
 - special purpose assignments for which special treatment should be
 configurable by the IP stacks
 
 (see
 https://www.ietf.org/ibin/c5i?mid=6rid=49gid=0k1=933k2=66219tid=13
 56023982)
 
 In its current form the content of the new registry documented by the
 I-D does not make a distinction between the two categories. There are
 two solutions to overcome this, one would be to define separate
 registries, the other to add a field to the current tables that makes
 the distinction between the two.

The later approach is taken in version-04

 
 Minor issues:
 
 1. The Security Considerations section in RFC 5156 which is obsoleted
 by this document included:
 
Filtering the invalid routing prefixes listed in this document
 should
improve the security of networks.
 
 This has not been taken upon by the new I-D, although it looked like a
 useful recommendation.
 
 Similarly RFC 5735 included warning text about the unexpected usage of
 special purposes addresses which was not carried over in this document.

These are both useful recommendations, but beyond the scope of the current 
document, which is an instruction to IANA. This kind of advice should be in an 
OPSEC document.

 
 2. RFC 5735 included in the IANA consideration section the following
 recommendation:
 
As required by [RFC2860], the IANA will also make necessary
experimental assignments of IPv4 addresses, also in consultation
 with
the Regional Internet Registries.
 
 There is no such recommendation in the new proposal, actually there is
 nothing about experimental assignments.

RFC 5735 doesn't make any recommendation. It reiterates a requirement stated in 
RFC 2860. Since the current document does not obsolete, update or in any way 
affect RFC 2860, there is no need to reiterate that long-standing requirement.

 
 Nits/editorial comments:
 
 In Table 11 Allocation Date is stated as February 196 - needs to be
 corrected (probably February 1996)
 

Good Catch.

 


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

Re: [Gen-art] Gen-art review of draft-gont-intarea-obsolete-eid-option-01

[Ronald Bonica]

Thanks for these comments. They have all been addressed by means of an RFC 
editor note.

 Ron


 -Original Message-
 From: iesg-boun...@ietf.org [mailto:iesg-boun...@ietf.org] On Behalf Of
 Moriarty, Kathleen
 Sent: Thursday, October 25, 2012 4:36 PM
 To: gen-art@ietf.org; draft-gont-intarea-obsolete-eid-
 option@tools.ietf.org; i...@ietf.org
 Cc: fg...@si6networks.com
 Subject: Gen-art review of draft-gont-intarea-obsolete-eid-option-01
 
 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-gont-intarea-obsolete-eid-option-01
 Reviewer: Kathleen Moriarty
 Review Date: 10/25/12
 IETF LC End Date: 11/1/12
 IESG Telechat date: (if known)
 
 Summary:  The document needs a few small revisions.
 This document formally deprecates the IPv6 Endpoint Identification
 (EID) option (hex value 0x8a).
 
 Major issues:
 
 Minor issues:
 RFC2119 is referenced, but not used.  I don't see the use of any
 RFC2119 language in the document, so it may be safe to remove this
 reference.
 
 I don't think the reference for EID option is valid.  I also looked at
 the reference in the IANA page and that no longer contains a link.
 From a google search, it looks like this was an internet draft that was
 never published as an RFC and expired, http://ana-
 3.lcs.mit.edu/~jnc/nimrod/eidoption.txt
 Listing it as A work in progress when it is an expired draft s not
 appropriate.
 
 Nits/editorial comments:
 
 I recommend changing the following portion of the abstract to state
 what is accomplished in this draft as the language is a little
 confusing:
 possibly serving as a basis for providing advice
 Since this draft doesn't actually provide the advice, just says it may
 provide a basis for providing the advice, I would recommend leaving
 this out of the abstract.
 
 Recommend removing e.g. fromt he last sentence int he Security
 Considerations section as it is not needed.
 Change from:
 However, formally deprecating this option
may serve as a basis for e.g. providing advice about filtering
packets containing such option (in a similar way to
[I-D.ietf-opsec-ip-options-filtering] for the IPv4 case).
 TO:
 However, formally deprecating this option
may serve as a basis for providing advice about filtering
packets containing such option (in a similar way to
[I-D.ietf-opsec-ip-options-filtering] for the IPv4 case).
 
 
 Thank you,
 Kathleen

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

Re: [Gen-art] (full/final) review of draft-ietf-opsawg-oam-overview-05.txt

[Ronald Bonica]

 
 PS: I've downgraded the ICMP traceroute point to minor.

Francis,

Thanks for catching this one. While it may not be major, it is embarrassing. I 
have proposed alternative text.

 Ron

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