Black, David | 21 Apr 01:54 2015

Gen-ART review of draft-ietf-v6ops-cidr-prefix-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 resolve these comments along with any other Last Call comments
you may receive.

Document: draft-ietf-v6ops-cidr-prefix-01
Reviewer: David Black
Review Date: April 20, 2015
IETF LC End Date: April 20, 2015

Summary: This draft is basically ready for publication, but has nits that
	should be fixed before publication.

This is a short crisp draft on behavior of CIDR prefixes in IPv6 forwarding
with respect to the /64 boundary in IPv6 addresses.  It's clear, well explained
easy to understand, plus refreshingly short.  Nicely done!

Major issues: (none)

Minor issues: (none)

Nits/editorial comments: Ok, I found a nit ... and so did idnits ;-).

-- Abstract

   Hardware and software
   algorithms should therefore impose no rules on prefix length, but
(Continue reading)

Wassim Haddad | 20 Apr 20:42 2015
Picon

Gen-ART Review of draft-ietf-dane-srv-13

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-dane-srv-13
Reviewer:  Wassim Haddad
Review Date: 20 April 2015
IETF LC End Date: 17 April 2015
IETF Telechat Date: unknown

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 <at> ietf.org
https://www.ietf.org/mailman/listinfo/gen-art
Tom Taylor | 18 Apr 00:04 2015
Picon

Last Call Review of draft-ietf-tls-negotiated-ff-dhe-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 resolve these comments along with any other Last Call comments
you may receive.

Document: draft-ietf-tls-negotiated-ff-dhe-08
Reviewer: Tom Taylor
Review Date: 17 April 2015
IETF LC End Date: 17 April 2015
IESG Telechat date: (if known)

Summary: Ready with minor issues and nits. I did not attempt to verify 
the hexadecimal expansions of p and q in Appendix A.

Major issues:

Minor issues:

1. Section 3 third paragraph: to what does "these values" refer? Any 
supported group at all, or specifically FFDHE groups? Nit: the ALSO is 
not part of RFC 2119 terminology, so should not be capitalized. The 
usual question: why SHOULD rather than MUST?

2. Why SHOULDs rather than MUSTs in the first paragraph of Section 4? 
What alternative does the server have in these cases?

Nits/editorial comments:

1. IDNits complains that the Abstract does not list the RFCs updated by 
this one. You need to add a statement like: "This document updates RFC 
2246, RFC 4346, RFC 4492, and RFC 5246."

2. Section 1, second-last paragraph, third line: s/;/ and/

3. Section 3 fourth paragraph: s/who/that/

4. Section 8, second paragraph, third line: s/it/IANA/

5. Section 9.1, first line: s/is hashed/are hashed/

6. Section 9.1, second indented paragraph under "An attacker who 
impersonates the client ...":
First line ends in an incomplete thought "(e.g. by ."

7. Same location, all three indented paragraphs: "e.g." has to be 
followed by a comma.

8. Section 9.2, first para, third line: s/which defines/that define/

9. Annex A.x, several instances: s/calcluated/calculated/
Russ Housley | 17 Apr 18:25 2015

Gen-ART Review of draft-ietf-rtgwg-mofrr-06

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

This review is in response to a request for early Gen-ART review.

Document: draft-ietf-rtgwg-mofrr-06
Reviewer: Russ Housley
Review Date: 2015-04-17
IETF LC End Date: 2015-04-30
IESG Telechat date: unknown

Summary: Almost Ready

Major Concerns:

None

Minor Concerns:

Please add POP to the list of terms in Section 1.2.

The introduction to Section 6 really only talks about Section 6.1.
Perhaps Sections 6 and 6.1 should be merged.  If they are merged, it
could look like this: 

   6.  MoFRR Applicability to Dual-Plane Topology

   MoFRR applicability is topology dependent.  The applicability is the
   same as LFA FRR which is discussed in [RFC6571].

   MoFRR works best in dual-planes topologies as illustrated in the
   figures below.  MoFRR may be enabled on any router in the network.
   In the figures below, MoFRR is shown enabled on the Provider Edge
   (PE) routers to illustrate one way in which the technology may be
   deployed.

   . . . 

If this suggestion is taken, Sections 6.2, 6.3, and 6.4 could become
top-level sections of their own.

Other Comments:

The figures are referenced in many ways: FIG3, Fig3, and Fig 3.
Please pick one style and use it throughout the document.

Section 1, 2nd paragraph: add a period at the end of the paragraph.

Section 1.2, LFA definition: add a period after the first sentence.

Section 4, intro paragraph: Delete "  See below;" from the end.

Section 5, 1st paragraph: s/section explore some/section explores some/
Roni Even | 17 Apr 09:13 2015
Picon

Gen-ART LC review of draft-ietf-uta-xmpp-06

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

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

Document:  draft-ietf-uta-xmpp-06

Reviewer: Roni Even

Review Date:2015–4-17

IETF LC End Date: 2015–4-13

IESG Telechat date: 2015–4-23

 

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

I reviewed the latest version and it addresses my comments on the 05 version

 

Major issues:

 

Minor issues:

 

 

_______________________________________________
Gen-art mailing list
Gen-art <at> ietf.org
https://www.ietf.org/mailman/listinfo/gen-art
Meral Shirazipour | 17 Apr 04:39 2015
Picon

Gen-ART Last Call review of draft-ietf-nfsv4-layout-types-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-ietf-nfsv4-layout-types-03
Reviewer: Meral Shirazipour
Review Date: 2015-04-16
IETF LC End Date:  2015-04-16
IESG Telechat date: NA

Summary:
This draft is ready to be published as Standards Track RFC but it has some nits.

Major issues:

Minor issues:

Nits/editorial comments:

-[Page 1], Abstract, "those those specifically", remove extra "those"
-[Page 6], end of 3.2, "if at all possible,"--->"if at all possible."
-[Page 6], section 3.3, "separably"--->"separately"
- [Page 10], ref [FlexFiles] has a new version 05 now
- [Page 10], ref [Lustre]  is expired. Should be removed?

Best Regards,
Meral
---
Meral Shirazipour
Ericsson
Research
www.ericsson.com
A. Jean Mahoney | 17 Apr 00:09 2015

Assignments for the 2015-04-23 Telechat

Hi all,

The following reviewers have assignments:

Reviewer            LC end       Draft
------------------------------------------------------------------------------------
Christer Holmberg   2015-04-08 
draft-ietf-isis-extended-sequence-no-tlv-05 **

David Black         2015-04-15   draft-ietf-tram-stun-origin-05 **

Elwyn Davies        2015-03-18   draft-ietf-bess-mvpn-bidir-04 **

Francis Dupont      2015-04-02   draft-ietf-httpauth-digest-18 *

Joel Halpern        2015-04-07   draft-ietf-scim-use-cases-06 *

Roni Even           2015-04-13   draft-ietf-uta-xmpp-06 *

Wassim Haddad       2015-03-02 draft-ietf-eman-applicability-statement-10
Wassim Haddad       2015-04-17   draft-ietf-dane-srv-13 *

* Earlier draft reviewed
** Already reviewed

I have made the assignments in the review tool:
http://art.tools.ietf.org/tools/art/genart/

And the assignments are captured in the spreadsheets:
http://wiki.tools.ietf.org/dav/genart/gen-art.html
http://wiki.tools.ietf.org/dav/genart/gen-art-by-reviewer.html

For your convenience, the review boilerplate template is included below.

Note that reviews should ideally be posted to the gen-art mailing list
by COB on Tuesday:
http://wiki.tools.ietf.org/area/gen/trac/wiki/

Jean

-------------------------------------------------------------------

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

Summary:

Major issues:

Minor issues:

Nits/editorial comments:
A. Jean Mahoney | 16 Apr 23:59 2015

A *new* batch of IETF LC reviews - 2015-04-16

Hi all,

The following reviewers have assignments:

Reviewer          LC end       Draft
---------------------------------------------------------------------
Martin Thomson    2015-04-23   draft-ietf-intarea-gre-mtu-02

Meral Shirazipour 2015-04-28   draft-ietf-lisp-eid-block-10 *

Peter Yee         2015-04-28   draft-ietf-lisp-eid-block-mgmnt-04

Robert Sparks     2015-04-28   draft-ietf-precis-saslprepbis-15

Roni Even         2015-05-13   draft-jimenez-p2psip-coap-reload-08

Russ Housley      2015-04-30   draft-ietf-rtgwg-mofrr-06

* 2nd LC (draft had expired in 2013)

I have made the assignments in the review tool:
http://art.tools.ietf.org/tools/art/genart/

And the assignments are captured in the spreadsheets:
http://wiki.tools.ietf.org/dav/genart/gen-art.html
http://wiki.tools.ietf.org/dav/genart/gen-art-by-reviewer.html

The standard template is included below.

Thanks,

Jean

-------------------------------------------------------------------

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

Summary:

Major issues:

Minor issues:

Nits/editorial comments:
Jeff Haas | 10 Apr 23:11 2015
Picon

Re: [IANA #818133] Last Call: <draft-ietf-idr-flowspec-redirect-rt-bis-03.txt> (Clarification of the Flowspec Redirect Extended Community) to Proposed Standard

+gen-art review who noted similar issues in the registration policy

On Apr 10, 2015, at 12:37 PM, Pearl Liang via RT <drafts-lastcall <at> iana.org> wrote:

> Hi Sue, and Jeff,
> 
> Thank you Sue for clarifying the timeline and the IANA actions.  Your instructions are very 
> clear.  Just a few nits/question.  
> 
> - Regarding the Form for new created registries:
> 
> Form: Sub-type Value, Name, Reference, Registration Type
> 
> Can you clarify what types of information will go to the element "Registration Type"
> in the BGP Extended Communities registry?

I believe Sue had intended this to match the form of the existing "Generic Transitive Experimental Use
Extended Community Sub-Types" registry.  This includes sub-type value and name as fields with reference
to the document and date.  Is that right, Sue?

> 
> - This is likely for Jeff.  I noticed now that the two new registrations for Part 2 
> Sub-Types and Part 3 Sub-Types have different names in the IC section:
> 
> /snip/
> IANA is requested to create the "Generic Transitive Experimental Use
> Extended Community Part 2 Sub-Types" registry.  It should be seeded
>   with the following Sub-Type:
> 
>   0x08 - Flow spec redirect IPv4 format.
> 
>   IANA is requested to create the "Generic Transitive Experimental Use
>   Extended Community Part 3 Sub-Types" registry.  It should be seeded
>   with the following Sub-Type:
> 
>   0x08 - Flow spec redirect AS-4byte format.
> /snip/

I think the text was unclear.  The intention is to create two new registries in the form of the "Generic
Transitive Experimental Use Extended Community Sub-Type".  The new registries are distinct in that the
first octet value (the type) is 0x81 and 0x82 for Part 2 and Part 3 respectively.

Within each of those registries, there is a single entry registered,as per above.

Please see the attachment at the end of this mail for new proposed IANA Considerations text that I believe
conveys this intent.  It contains all edits to date.

> 
> Please update the names to the one in Sue's comment if the names should 
> be consistent in both sub-regisries.
> 
> I'll let you work on the action items on your end.  If you have questions for us,
> please contact us.
> 
> Thanks,
> ~pl
> 
> 
> On Fri Apr 10 00:33:05 2015, shares <at> ndzh.com wrote:
>> Pearl:
>> 
>> This is my understanding of what needs to change, and hopefully
>> answers all your questions.  I apologize that this draft got to you
>> without the new form.
>> 
>> I'll wait for an acknowledgement from Jeff that he is re-writing the
>> draft to cover these changes. Once Jeff has re-written the draft, this
>> draft will be 1 week WG LC to cover this change.  Please set your
>> timer to check on this in 2 week.
>> 
>> Answers to your questions:
>> O Action 1, Q1: the RFC should be [RFC5575, RFC-to-Be]
>> On Action 2, this is correct,  Please update the free space in the
>> registry to indicate only 0x83 to 0x8f are free.

Agreed.

>> 
>> On action 3, Q1:  Please create a new entry under the following web-
>> page
>> http://www.iana.org/assignments/bgp-extended-communities/bgp-extended-
>> communities.xhtml
>> 
>> Name the web page the following:
>> "Generic Transitive Experimental Use
>>  Extended Community Part 2 Sub-Types" registry.
>> 
>> Form: Sub-type Value, Name, Reference, Registration Type
>> 
>> Sub-Type Value  Name                     Reference  Registration-type
>> 0x00-0x07        TBD                         TBD
>> Standards action
>> 
>> 0x08               Flow Spec redirect
>>                       AS-4byte format      [This-RFC]   Standards
>> 
>> 0x09-0x40     TBD                            TBD             Standards
>> action
>> 0x41-0xff   Reserved

Sue, is there any reason to not use a similar registration range as the 0x80 range?  I.e.:
0x00-0xbf - FCFS
0xc0-0xff - IETF review?

>> 
>> 
>> On action 3, Q4:
>> Please create a new entry under the following web-page
>> http://www.iana.org/assignments/bgp-extended-communities/bgp-extended-
>> communities.xhtml
>> 
>> Name the web page the following:
>> "Generic Transitive Experimental Use
>>  Extended Community Part 3 Sub-Types" registry.
>> 
>> Form: Sub-type Value, Name, Reference, Registration Type
>> 
>> Example:
>> Sub-Type Value  Name                   Reference  Registration-type
>> 0x00-0x07        TBD                         TBD
>> Standards action
>> 
>> 0x08               Flow Spec redirect
>>                       AS-4byte format      [This-RFC]   Standards
>> 
>> 0x09-0x40     TBD                            TBD             Standards
>> action
>> 0x41-0xff   Reserved
>> 
>> 
>> Sue Hares
>> 
>> -----Original Message-----
>> From: Pearl Liang via RT [mailto:drafts-lastcall <at> iana.org]
>> Sent: Tuesday, April 07, 2015 2:42 PM
>> Cc: draft-ietf-idr-flowspec-redirect-rt-bis <at> tools.ietf.org;
>> idr <at> ietf.org; idr-chairs <at> ietf.org
>> Subject: [IANA #814082] Last Call: <draft-ietf-idr-flowspec-redirect-
>> rt-bis-03.txt> (Clarification of the Flowspec Redirect Extended
>> Community) to Proposed Standard
>> 
>> (BEGIN IANA LAST CALL COMMENTS)
>> 
>> IESG/Authors/WG Chairs:
>> 
>> IANA has reviewed draft-ietf-idr-flowspec-redirect-rt-bis-03.  Authors
>> should review the comments and/or questions below.  Please report any
>> inaccuracies and respond to any questions as soon as possible.
>> 
>> IANA has several questions about some of the actions requested in the
>> IANA Considerations section of this document.
>> 
>> We received the following comments/questions from the IANA's reviewer:
>> 
>> IANA understands that, upon approval of this document, there are four
>> actions which IANA is required to complete.
>> 
>> First, in the Generic Transitive Experimental Use Extended Community
>> Sub-Types subregistry of the Border Gateway Protocol (BGP) Extended
>> Communities registry located at:
>> 
>> http://www.iana.org/assignments/bgp-extended-communities/
>> 
>> the existing registration for Type Value 0x08 will have its name
>> updated from:
>> 
>> Flow spec redirect
>> 
>> to:
>> 
>> Flow spec redirect AS-2byte format
>> 
>> and have the reference changed to [ RFC-to-be ]
>> 
>> QUESTION [1]:  This draft indicates that it updates RFC5575 according
>> to the header information in the draft.  Is the author intended to
>> remove the existing defining reference from the registry?
>> 
>> 
>> Second, in the BGP Transitive Extended Community Types subregistry
>> also in the Border Gateway Protocol (BGP) Extended Communities
>> registry located at:
>> 
>> http://www.iana.org/assignments/bgp-extended-communities/
>> 
>> two new registrations will be added as follows:
>> 
>> Type Value: 0x81
>> Name: Generic Transitive Experimental Use Extended Community Part 2
>> (Sub-Types are defined in the "Generic Transitive Experimental
>> Extended Community Part 2 Sub-Types" Registry)
>> Reference: [ RFC-to-be ]
>> 
>> Type Value: 0x82
>> Name: Generic Transitive Experimental Use Extended Community Part 3
>> (Sub-Types are defined in the "Generic Transitive Experimental
>> Extended Community Part 3 Sub-Types" Registry)
>> Reference: [ RFC-to-be ]
>> 
>> Third, a new registry is to be created called the "Generic Transitive
>> Experimental Use Extended Community Part 2 Sub-Types" registry.
>> 
>> IANA QUESTION [1]  -> Where should this new registry be located? Is it
>> a néw registry on the IANA Matrix or is it a subregistry of an
>> existing registry? If it is a subregistry of an existing registry, in
>> which registry will it be contained?  In the same BGP Extended
>> Communities located at http://www.iana.org/assignments/bgp-extended-
>> communities registry?
>> 
>> IANA QUESTION [2]  -> What rules should be used for maintenance of
>> this new registry? Please refer to RFC 5226 for guidance on how to
>> select and apply maintenance policy for a new registry.
>> 
>> QUESTION: [3] What is the range for this new Part 2 Sub-Types
>> registry?
>> 
>> QUESTION: [4] Is the author intended to use the same table format as
>> the existing sub-registry
>> "Generic Transitive Experimental Use Extended Community Sub-Types"
>> which has
>> the following columns: Sub-Type Value, Name, Reference, and
>> (Registration) Date?
>> 
>> IANA understands that there is a single initial registration in the
>> new registry as follows:
>> 
>> Type Value: 0x08
>> Name: Flow spec redirect IPv4 format
>> Reference: [ RFC-to-be ]
>> 
>> Fourth, a new registry is to be created called the "Generic Transitive
>> Experimental Use Extended Community Part 3 Sub-Types" registry.
>> 
>> IANA QUESTION [1] -> Where should this new registry be located? Is it
>> a néw registry on the IANA Matrix or is it a subregistry of an
>> existing registry? If it is a subregistry of an existing registry, in
>> which registry will it be contained?
>> 
>> IANA QUESTION [2] -> What rules should be used for maintenance of this
>> new registry? Please refer to RFC 5226 for guidance on how to select
>> and apply maintenance policy for a new registry.
>> 
>> QUESTION: [3] What is the range for this new Part 3 Sub-Types
>> registry?
>> 
>> QUESTION: [4] Is the author intended to use the same table format as
>> the existing sub-registry
>> "Generic Transitive Experimental Use Extended Community Sub-Types"
>> which has
>> the following columns: Sub-Type Value, Name, Reference, and
>> (Registration) Date?
>> 
>> IANA understands that there is a single initial registration in the
>> new registry as follows:
>> 
>> Type Value: 0x08
>> Name: FFlow spec redirect AS-4byte format
>> Reference: [ RFC-to-be ]
>> 
>> IANA understands that these four actions are the only ones required to
>> be completed upon approval of this document.
>> 
>> Note:  The actions requested in this document will not be completed
>> until the document has been approved for publication as an RFC. This
>> message is only to confirm what actions will be performed.
>> 
>> Please note that IANA cannot reserve specific values. However, early
>> allocation is available for some types of registrations. For more
>> information, please see RFC 7120.
>> 
>> Thanks,
>> 
>> Pearl Liang
>> ICANN
>> 
>> (END IANA LAST CALL COMMENTS)
>> 
>> 
>> On Wed Mar 18 20:33:49 2015, iesg-secretary <at> ietf.org wrote:
>>> 
>>> The IESG has received a request from the Inter-Domain Routing WG
>>> (idr)
>>> to
>>> consider the following document:
>>> - 'Clarification of the Flowspec Redirect Extended Community'
>>>  <draft-ietf-idr-flowspec-redirect-rt-bis-03.txt> as Proposed
>>> Standard
>>> 
>>> The IESG plans to make a decision in the next few weeks, and solicits
>>> final comments on this action. Please send substantive comments to
>>> the
>>> ietf <at> ietf.org mailing lists by 2015-04-08. Exceptionally, comments
>>> may
>>> be
>>> sent to iesg <at> ietf.org instead. In either case, please retain the
>>> beginning of the Subject line to allow automated sorting.
>>> 
>>> Abstract
>>> 
>>> 
>>> This document clarifies the formatting of the the BGP Flowspec
>>> Redirect Extended Community, originally documented in RFC 5575
>>> (Dissemination of Flow Specification Rules).
>>> 
>>> 
>>> 
>>> 
>>> The file can be obtained via
>>> http://datatracker.ietf.org/doc/draft-ietf-idr-flowspec-redirect-rt-
>>> bis/
>>> 
>>> IESG discussion can be tracked via
>>> http://datatracker.ietf.org/doc/draft-ietf-idr-flowspec-redirect-rt-
>>> bis/ballot/
>>> 
>>> 
>>> No IPR declarations have been submitted directly on this I-D.
> 
> 


Internet Engineering Task Force                             J. Haas, Ed.
Internet-Draft                                          Juniper Networks
Updates: 5575 (if approved)                               April 10, 2015
Intended status: Standards Track
Expires: October 12, 2015

       Clarification of the Flowspec Redirect Extended Community
               draft-ietf-idr-flowspec-redirect-rt-bis-04

Abstract

   This document updates RFC 5575 (Dissemination of Flow Specification
   Rules) to clarify the formatting of the the BGP Flowspec Redirect
   Extended Community.

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on October 12, 2015.

Copyright Notice

   Copyright (c) 2015 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Haas                    Expires October 12, 2015                [Page 1]

Internet-Draft   draft-ietf-idr-flowspec-redirect-rt-bis      April 2015

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   4
     2.1.  Update to BGP Generic Transitive Experimental  Use
           Extended Community Sub-Types  . . . . . . . . . . . . . .   4
     2.2.  Generic Transitive Experimental Extended Community Part 2
           Sub-Types . . . . . . . . . . . . . . . . . . . . . . . .   5
     2.3.  Generic Transitive Experimental Extended Community Part 3
           Sub-Types . . . . . . . . . . . . . . . . . . . . . . . .   5
   3.  Security Considerations . . . . . . . . . . . . . . . . . . .   6
   4.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .   6
   5.  Normative References  . . . . . . . . . . . . . . . . . . . .   6
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .   7

1.  Introduction

   Dissemination of Flow Specification Rules [RFC5575], commonly known
   as BGP Flowspec, provided for a BGP Extended Community [RFC4360] that
   served to redirect traffic to a VRF routing instance that matched the
   flow specification NLRI.  In that RFC, the Redirect Extended
   Community was documented as follows:

Haas                    Expires October 12, 2015                [Page 2]

Internet-Draft   draft-ietf-idr-flowspec-redirect-rt-bis      April 2015

   : +--------+--------------------+--------------------------+
   : | type   | extended community | encoding                 |
   : +--------+--------------------+--------------------------+
   : | 0x8008 | redirect           | 6-byte Route Target      |
   : +--------+--------------------+--------------------------+
   :
   : [...]
   :
   : Redirect:  The redirect extended community allows the traffic to be
   : redirected to a VRF routing instance that lists the specified
   : route-target in its import policy.  If several local instances
   : match this criteria, the choice between them is a local matter
   : (for example, the instance with the lowest Route Distinguisher
   : value can be elected).  This extended community uses the same
   : encoding as the Route Target extended community [RFC4360].
   : [...]
   :
   : 11. IANA Considerations
   : [...]
   :
   : The following traffic filtering flow specification rules have been
   : allocated by IANA from the "BGP Extended Communities Type -
   : Experimental Use" registry as follows:
   : [...]
   :
   : 0x8008 - Flow spec redirect

   The IANA registry of BGP Extended Communities clearly identifies
   communities of specific formats.  For example, "Two-octet AS Specific
   Extended Community" [RFC4360], "Four-octet AS Specific Extended
   Community" [RFC5668] and "IPv4 Address Specific Extended Community"
   [RFC4360].  Route Targets [RFC4360] identify this format in the high-
   order (Type) octet of the Extended Community and set the value of the
   low-order (Sub-Type) octet to 0x02.  The Value field of the Route
   Target Extended Community is intended to be interpreted in the
   context of its format.

   Since the Redirect Extended Community only registered a single code-
   point in the IANA BGP Extended Community registry, a common
   interpretation of the redirect extended community's "6-byte route
   target" has been to look, at a receiving router, for a route target
   value that matches the route target value in the received redirect
   extended community, and import the advertised route to the
   corresponding VRF instance subject to the rules defined in [RFC5575].
   However, because the route target format in the redirect extended
   community is not clearly defined, the wrong match may occur.

Haas                    Expires October 12, 2015                [Page 3]

Internet-Draft   draft-ietf-idr-flowspec-redirect-rt-bis      April 2015

   This "value wildcard" matching behavior, which does not take into
   account the format of the route target defined for a local VRF and
   may result in the wrong matching decision, does not match deployed
   implementations of BGP Flowspec.  Deployed implementations of BGP
   Flowspec solve this problem by defining different redirect extended
   communities that are specific to the format of the route target
   value.  This document defines the following redirect extended
   communities:

   +--------+--------------------+-------------------------------------+
   | type   | extended community | encoding                            |
   +--------+--------------------+-------------------------------------+
   | 0x8008 | redirect AS-2byte  | 2-octet AS, 4-octet Value           |
   | 0x8108 | redirect IPv4      | 4-octet IPv4 Address, 2-octet Value |
   | 0x8208 | redirect AS-4byte  | 4-octet AS, 2-octet Value           |
   +--------+--------------------+-------------------------------------+

   It should be noted that the low-order nybble of the Redirect's Type
   field corresponds to the Route Target Extended Community format field
   (Type).  (See [RFC4360], Secs. 3.1, 3.2, and 4 plus [RFC5668], Sec.
   2.)  The low order octet (Sub-Type) of the Redirect Extended
   Community remains 0x08, contrasted to 0x02 for Route Targets.

   The IANA Registries for BGP Extended Communities [RFC7153] document
   was written to update the previously-mentioned IANA registries to
   better document BGP Extended Community formats.  The IANA
   Considerations section below further amends those registry updates in
   order to properly document the Flowspec redirect communities.

2.  IANA Considerations

2.1.  Update to BGP Generic Transitive Experimental Use Extended
      Community Sub-Types

   IANA is requested to update the "BGP Generic Transitive Experimental
   Use Extended Community Sub-Types" registry as follows:

   0x08 - Flow spec redirect AS-2byte format. [RFC5575, RFC-to-be]

   (Note to RFC Editor - replace RFC-to-be with this RFC number.)

   IANA is requested to update the "BGP Transitive Extended Community
   Types" registry as follows:

Haas                    Expires October 12, 2015                [Page 4]

Internet-Draft   draft-ietf-idr-flowspec-redirect-rt-bis      April 2015

      0x81 - Generic Transitive Experimental Use Extended Community
             Part 2 (Sub-Types are defined in the "Generic Transitive
             Experimental Extended Community Part 2 Sub-Types" Registry)
      0x82 - Generic Transitive Experimental Use Extended Community
             Part 3 (Sub-Types are defined in the "Generic Transitive
             Experimental Extended Community Part 3 Sub-Types" Registry)

2.2.  Generic Transitive Experimental Extended Community Part 2 Sub-
      Types

   IANA is requested to create the "Generic Transitive Experimental Use
   Extended Community Part 2 Sub-Types" registry.  This registry should
   be created under http://www.iana.org/assignments/bgp-extended-
   communities/bgp-extended-communities.xhtml.  It will contain the
   following note:

      This registry contains values of the second octet (the "Sub-Type"
      field) of an extended community when the value of the first octet
      (the "Type" field) is 0x81.

   Registry Name: Generic Transitive Experimental Use Extended Community
   Part 2 Sub-Types

       RANGE              REGISTRATION PROCEDURE           REFERENCE

       0x00-0xBF          First Come First Served
       0xC0-0xFF          IETF Review

       SUB-TYPE VALUE     NAME
       0x00-0x07          Unassigned
       0x08               Flow spec redirect IPv4 format.  [RFC-to-be]
       0x09-0xff          Unassigned

   (Note to RFC Editor - replace RFC-to-be with this RFC number.)

2.3.  Generic Transitive Experimental Extended Community Part 3 Sub-
      Types

   IANA is requested to create the "Generic Transitive Experimental Use
   Extended Community Part 3 Sub-Types" registry.  This registry should
   be created under http://www.iana.org/assignments/bgp-extended-
   communities/bgp-extended-communities.xhtml.  It will contain the
   following note:

      This registry contains values of the second octet (the "Sub-Type"
      field) of an extended community when the value of the first octet
      (the "Type" field) is 0x82.

Haas                    Expires October 12, 2015                [Page 5]

Internet-Draft   draft-ietf-idr-flowspec-redirect-rt-bis      April 2015

   Registry Name: Generic Transitive Experimental Use Extended Community
   Part 2 Sub-Types

     RANGE              REGISTRATION PROCEDURE               REFERENCE

     0x00-0xBF          First Come First Served
     0xC0-0xFF          IETF Review

     SUB-TYPE VALUE     NAME
     0x00-0x07          Unassigned
     0x08               Flow spec redirect AS-4byte format.  [RFC-to-be]
     0x09-0xff          Unassigned

   (Note to RFC Editor - replace RFC-to-be with this RFC number.)

3.  Security Considerations

   This document introduces no additional security considerations than
   those already covered in [RFC5575].  It should be noted that if the
   wildcard behavior were actually implemented, this ambiguity may lead
   to the installation of Flowspec rules in an incorrect VRF and may
   lead to traffic to be incorrectly delivered.

4.  Acknowledgements

   The contents of this document was raised as part of implementation
   discussions of BGP Flowspec with the following individuals:

      Andrew Karch (Cisco)

      Robert Raszuk

      Adam Simpson (Alcatel-Lucent)

      Matthieu Texier (Arbor Networks)

      Kaliraj Vairavakkalai (Juniper)

5.  Normative References

   [RFC4360]  Sangli, S., Tappan, D., and Y. Rekhter, "BGP Extended
              Communities Attribute", RFC 4360, February 2006.

   [RFC5575]  Marques, P., Sheth, N., Raszuk, R., Greene, B., Mauch, J.,
              and D. McPherson, "Dissemination of Flow Specification
              Rules", RFC 5575, August 2009.

Haas                    Expires October 12, 2015                [Page 6]

Internet-Draft   draft-ietf-idr-flowspec-redirect-rt-bis      April 2015

   [RFC5668]  Rekhter, Y., Sangli, S., and D. Tappan, "4-Octet AS
              Specific BGP Extended Community", RFC 5668, October 2009.

   [RFC7153]  Rosen, E. and Y. Rekhter, "IANA Registries for BGP
              Extended Communities", RFC 7153, March 2014.

Author's Address

   Jeffrey Haas (editor)
   Juniper Networks

   Email: jhaas <at> juniper.net

Haas                    Expires October 12, 2015                [Page 7]
_______________________________________________
Gen-art mailing list
Gen-art <at> ietf.org
https://www.ietf.org/mailman/listinfo/gen-art
Wassim Haddad | 10 Apr 01:09 2015
Picon

Gen-ART Review of draft-ietf-dane-srv-12

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-dane-srv-12
Reviewer:  Wassim Haddad
Review Date: 09 April 2015
IETF LC End Date: 17 April 2015
IETF Telechat Date: unknown

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 <at> ietf.org
https://www.ietf.org/mailman/listinfo/gen-art
A. Jean Mahoney | 9 Apr 17:49 2015

A *new* batch of IETF LC reviews - 2015-04-09

Hi all,

The following reviewers have assignments:

Reviewer          LC end       Draft
---------------------------------------------------------------------
Alexey Melnikov   2015-04-20   draft-ietf-bmwg-traffic-management-04

Christer Holmberg 2015-04-20   draft-ietf-opsawg-hmac-sha-2-usm-snmp-05

David Black       2015-04-20   draft-ietf-v6ops-cidr-prefix-01

Elwyn Davies      2015-04-20   draft-ietf-scim-core-schema-17

Francis Dupont    2015-04-20   draft-ietf-scim-api-16

Joel Halpern      2015-05-05   draft-hallambaker-tlsfeature-09

Tom Taylor        2015-04-17   draft-ietf-tls-negotiated-ff-dhe-08

Wassim Haddad     2015-04-17   draft-ietf-dane-srv-12

I have made the assignments in the review tool:
http://art.tools.ietf.org/tools/art/genart/

And the assignments are captured in the spreadsheets:
http://wiki.tools.ietf.org/dav/genart/gen-art.html
http://wiki.tools.ietf.org/dav/genart/gen-art-by-reviewer.html

The standard template is included below.

Thanks,

Jean

-------------------------------------------------------------------

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

Summary:

Major issues:

Minor issues:

Nits/editorial comments:

Gmane