Brian E Carpenter | 20 Oct 02:09 2014

Gen-ART Last Call review of draft-ietf-weirds-rdap-query-15

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-weirds-rdap-query-15.txt
Reviewer: Brian Carpenter
Review Date: 2014-10-20
IETF LC End Date: 2014-10-24
IESG Telechat date: 2014-10-30

Summary:   Almost ready

Major Issues:

Section 3.1.1 says:

  "The restricted
   rules to write a text representation of an IPv6 address [RFC5952] are
   not mandatory."

Why not make 5952 at least a SHOULD? Personally, I would make it a MUST. As 5952 itself states,
the ambiguity of the RFC 4291 format creates many problems. 5952 in any case requires that
"all implementations must accept and be able to handle any legitimate RFC 4291 format",
so making conformance with 5952 a SHOULD or MUST won't break anything.

(Continue reading)

Adrian Farrel | 17 Oct 13:05 2014

Re: GenART review of draft-ietf-l2vpn-evpn-10

Hi Martin,

I firmly believe that all reviews are good reviews, and thank you for the time
you have put into this.

You'll understand, of course, the squawking noise made by the authors who
received your review the day after the IESG discussed your document on the
telechat. In fact, the last Discus cleared a short while ago, and I was just
about to click the friendly red button marked "Approved".  Including the
standard GenArt boilerplate about "last call comments" might be a tiny but
ironic :-)

But let's cut to the chase...

> I found the overview in Section 4 to be very...wooly.  

I re-read and found it relatively to the point.
Sentences are quite short, and are all definitive.

> It launches
> straight into alphabet soup, 

True there are a lot of abbreviations.
But the terms are either well-known or described in Section 3.
For example, if a reader is unfamiliar with CE, PE, MPLS, IP, GRE, then I'm
afraid they will get nothing out of the document. Expanding the terms will not

> but didn't manage to identify what it was
(Continue reading)

Martin Thomson | 17 Oct 01:57 2014

GenART review of draft-ietf-l2vpn-evpn-10

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-l2vpn-evpn-10
Reviewer: Martin Thomson
Review Date: 2014-10-16
IETF LC End Date: past
IESG Telechat date: 2014-10-16

Summary: I found no major issues here, but I'm not able to give this
proper time to do this justice.  I have some comments, but these need
to be considered in context of the time I've spent on this.  I'm
guessing a week might be adequate, but that's time I don't have for


I found the overview in Section 4 to be very...wooly.  It launches
straight into alphabet soup, but didn't manage to identify what it was
that the document was trying to achieve, vs. what already exists.  It
certainly raises questions: is this document going to address the
issue of how MAC learning is populated on devices in networks attached
to CE?  Is it going to deal with (MAC) learning on the PE and CE
equipment?  What information does the CE really need at the MAC layer
to do its job?  The information provided is definitely not enough to
(Continue reading)

A. Jean Mahoney | 17 Oct 00:13 2014

A *new* batch of IETF LC reviews - 2014-10-16

Hi all,

The following reviewers have assignments:

Reviewer          LC end       Draft

Alexey Melnikov   2014-10-24   draft-ietf-rtcweb-data-protocol-08

Ben Campbell      2014-10-24   draft-ietf-weirds-object-inventory-05 *

Brian Carpenter   2014-10-24   draft-ietf-weirds-rdap-query-15 *

Christer Holmberg 2014-10-24   draft-ietf-weirds-rdap-sec-09 ***, *

Dan Romascanu     2014-10-24   draft-ietf-weirds-json-response-10, *

David Black       2014-10-27   draft-ietf-payload-g7110-03

Elwyn Davies      2014-10-27   draft-ietf-mpls-mldp-in-band-wildcard-encoding-02 *

Francis Dupont    2014-10-27   draft-ietf-mpls-ipv6-only-gap-02

Joel Halpern      2014-10-24   draft-ietf-weirds-using-http-13 **, *

Martin Thomson    2014-10-27   draft-ietf-manet-ibs-03

Meral Shirazipour 2014-10-27   draft-ietf-l3vpn-mvpn-mldp-nlri-06

Robert Sparks     2014-10-27   draft-ietf-pce-wson-routing-wavelength-14
(Continue reading)

Peter Yee | 15 Oct 08:53 2014

Gen-ART Telechat review of draft-ietf-v6ops-ipv6-roaming-analysis-06

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

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

Document: draft-ietf-v6ops-ipv6-roaming-analysis-06
Reviewer: Peter Yee
Review Date: October-14-2014
IETF LC End Date: September-29-2014
IESG Telechat date: October-16-2014

Summary: This draft is ready with issues for publication as an Informational
RFC. [Ready with issues]

This draft discusses some of the issues that may occur when a mobile device
roams on a visited network and attempts to use IPv6.  The technical meat of
the draft is fine, but the language usage makes it difficult to read through
without extra effort and reflection.  I'm not a 3GPP expert by any stretch
of the imagination, so I can't tell if the analysis made is sufficiently
comprehensive, but it appears to cover all of the IPv4/IPv6 combinations and
home/local breakout uses cases.

The following corrections appeared in my -05 review and have not been
addressed.  I have not updated the page numbers to match any border cases
that might have moved one way or another, but the section numbers should be

Minor issues: 
(Continue reading)

Romascanu, Dan (Dan | 13 Oct 15:58 2014

Gen-ART Telechat Review of draft-ietf-grow-ix-bgp-route-server-operations-03.txt

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.



Reviewer: Dan Romascanu

Review Date: 9/18/14

IETF LC End Date: 9/22/14

IESG Telechat date: 10/16/14




This document was not updated since my initial review, so my comments still stand.


A useful and very well written document, with a few minor issues that need clarification and fixes before publication


Major issues:




Minor issues:


1.       The reference [RS-ARCH] mentioned in and is not reachable (Error 404). As the understanding of the issues described in the two sections depend on this reference, a valid reference is required.

2.       Section uses the term ‘flat layer 2 network’ which has at least two meanings depending on the context or layer – either one VLAN space at the link layer (as to differentiate from Customer VLAN and Provider VLAN) or a bridged network with no routers between the bridged segments. Clarification is needed.

3.       The usage of keywords is inconsistent in a few place. In 4.6.1 the ‘should’ in the second paragraph needs to be capitalized. In 4.6.3 we have a capitalized SHOULD, but then a non-capitalized ‘may’ for statements that both seem to describe requirements of the same level.

4.       I am doubt that Section 4.7 is that useful. On one hand reliability of layer 2 forwarding is not in my opinion such a big issue, and measures can be taken a the link layer to improve it (use lags or redundant paths). Second the recommended mitigation (RFC 5881 BFD) is described as non-optimal, with no other alternative. I would just drop this section completely.


Nits/editorial comments:


1.       The English syntax of the second paragraph in the Abstract is broken.

2.       In the introduction there is a mention of ‘using shared Layer-2 networking media such as Ethernet’. Actually Ethernet is seldom used nowadays as a shared media, I would just recommend saying ‘using data link layers protocols such as Ethernet’

3.       In section 4.2 s/optimization technique is implemented/optimization technique that is implemented/




Gen-art mailing list
Gen-art <at>
Black, David | 12 Oct 00:30 2014

Gen-ART and OPS-Dir review of draft-ietf-softwire-lw4over6-10

This is a combined Gen-ART and OPS-DIR review.  Boilerplate for both follows,
and I apologize for it being a day late - United Airlines got me back to
Boston after midnight last night on a plane w/o working WiFi.

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.

I have reviewed this document as part of the Operational directorate's ongoing
effort to review all IETF documents being processed by the IESG.  These comments
were written primarily for the benefit of the operational area directors.
Document editors and WG chairs should treat these comments just like any other
last call comments.

Document: draft-ietf-softwire-lw4over6-10
Reviewer: David Black
Review Date: October 10, 2014
IETF LC End Date: October 10, 2014
IESG Telechat date: October 16, 2014

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

This draft describes an extension to Dual-Stack Lite that relocates the NAPT
functionality from the centralized tunnel concentrator to the DS-Lite client
- doing so has significant scalability benefits.  The draft is generally
readable although understanding why some of the processing needs to be done
in the manner specified requires strong familiarity with both DS-Lite and

The draft is generally in good shape - I found three issues that I consider
to be significant, the most important of which are sloppiness in use of
RFC 2119 keywords, particularly in Section 5.1, and omission of what
appears to be a necessary normative reference.

Major issues (2):

[1] There are a number of places where SHOULD is used to refer to requirement
in another RFC, e.g., the following text in section 5.1:

   The DNS considerations described in Section 5.5 and Section 6.4 of
   [RFC6333] SHOULD be followed.

This has the side effect of weakening any MUST requirement in the referenced
RFC(s) to a SHOULD, which was probably not intended, and needs to be explicitly
stated if it was intended.  Here's a possible rephrasing:

   The DNS considerations described in Section 5.5 and Section 6.4 of
   [RFC6333] apply to Lightweight 4over6; lw4o6 implementations MUST
   comply with all requirements stated there.

The additional places where this occurs are:

- Section 5.2.1 (twice):

   For TCP and UDP traffic the NAPT44 implemented in the lwB4 SHOULD
   conform with the behaviour and best current practices documented in
   [RFC4787], [RFC5508], and [RFC5382].  If the lwB4 supports DCCP, then
   the requirements in [RFC5597] SHOULD be implemented.

- Section 8.2:

   The lwB4 SHOULD implement the requirements defined in [RFC5508] for
   ICMP forwarding.

[2] Section 4.  Lightweight 4over6 Architecture

   The consequence of this architecture is that the information
   maintained by the provisioning mechanism and the one maintained by
   the lwAFTR MUST be synchronized (See figure 2).  The details of this
   synchronization depend on the exact provisioning mechanism and will
   be discussed in a companion document.

I believe that this "companion document" needs to be cited as a
normative reference.  The above text's vague allusion to the specification
of how to implement a "MUST" requirement is insufficient.

Minor issues (7):

[3] The lack of discussion of management information is an
omission.  See A.2.2 below in the OPS-Dir review section of this email
and the discussion in Section 3.2 of RFC 5706.  A sentence pointing
at an applicable MIB and/or YANG draft or drafts would suffice.

[4] Section 4.  Lightweight 4over6 Architecture

   The solution specified in this document allows the assignment of
   either a full or a shared IPv4 address requesting CPEs.  [RFC7040]
   provides a mechanism for assigning a full IPv4 address only.

Please explain what entities would share the IPv4 address.  For example,
this is needed as a foundation for the statement in Section 8 that
"ICMPv4 does not work in an address sharing environment without
special handling [RFC6269]."

[5] Section 5.1.  Lightweight B4 Provisioning with DHCPv6

   For DHCPv6 based configuration of these parameters, the lwB4 SHOULD
   implement OPTION_S46_CONT_LW

What are the consequences of not doing that?  The could be addressed
by changing that "SHOULD" to a "MUST", although I suspect that what's
wanted here is a forward reference to the alternatives discussed in
Section 7.

[6] Also in Section 5.1

   If stateful IPv4 configuration or additional IPv4 configuration
   information is required, DHCPv4 [RFC2131] must be used.

"must" -> "MUST"

   In the event that the lwB4's encapsulation source address is changed
   for any reason (such as the DHCPv6 lease expiring), the lwB4's
   dynamic provisioning process must be re-initiated.

"must" -> "MUST"

[7] Also in Section 5.1

   Unless an lwB4 is being allocated a full IPv4 address, it is
   RECOMMENDED that PSIDs containing the well-known ports (0-1023) are
   not allocated to lwB4s.

Please explain why.  Also, "well-known ports" is not the right term;
I believe those are the "system ports", e.g., see:

[8] Still in Section 5.1

   In the event that the lwB4 receives an ICMPv6 error message (type 1,
   code 5) originating from the lwAFTR, the lwB4 SHOULD interpret this
   to mean that no matching entry in the lwAFTR's binding table has been
   found.  The lwB4 MAY then re-initiate the dynamic port-restricted
   provisioning process.  The lwB4's re-initiation policy SHOULD be

What happens if the lwB4 ignores the first "SHOULD"?

[9] Section 8.1.  ICMPv4 Processing by the lwAFTR

This describes two approaches to ICMPv4 processing.  Are there any others?
If so, please add some text about them, otherwise, I suggest this change:

   Additionally, the lwAFTR MAY implement:

   o  Discarding of all inbound ICMP messages.
   Otherwise the lwAFTR MUST discard all inbound ICMPv4 messages.

Nits/editorial comments:

-- Section 1.  Introduction

   Basic Bridging BroadBand element: A B4 element is a function
                                     implemented on a dual-stack capable
                                     node, either a directly connected
                                     device or a CPE, that creates a
                                     tunnel to an AFTR.

I suggest changing "a tunnel to an AFTR" to "an IPv4-in-IPv6 tunnel
to an AFTR" for consistency with the AFTR definition.

-- Section 5.2.  Lightweight B4 Data Plane Behavior

   Internally connected hosts source IPv4 packets with an [RFC1918]

Internal to what?  Please explain.

-- Section 6.2.  lwAFTR Data Plane Behavior

   The lwAFTR MUST support hairpinning of traffic between two lwB4s, by
   performing de-capsulation and re-encapsulation of packets.  The
   hairpinning policy MUST be configurable.

Please explain "hairpinning" - it should suffice to add "from one lwB4
that need to be sent to another lwB4 associated with the same AFTR"
after "de-capsulation and re-encapsulation of packets".

-- Section 7.  Additional IPv4 address and Port Set Provisioning Mechanisms

   In a Lightweight 4over6 domain, the binding information MUST be
   aligned between the lwB4s, the lwAFTRs and the provisioning server.

"aligned between" -> "synchronized across" for consistency with use
of forms of "synchronize" elsewhere in this draft.

idnits found a few things to complain about:

- The use of "the well-known range" in Section 5.1.  This is ok,
	as it's describing DS-Lite use of that range that is documented
	elsewhere.  If lw4o6 is using that range, an explanation ought to be
	added to Section 5.1.

- Three references have been updated:

  == Outdated reference: A later version (-09) exists of

  == Outdated reference: draft-ietf-dhc-dhcpv4-over-dhcpv6 has been published
     as RFC 7341

  == Outdated reference: A later version (-06) exists of

--- Selected RFC 5706 Appendix A Q&A for OPS-Dir review ---

A.1.1.  Has deployment been discussed?

	Yes, this protocol is intended to improve scalability over the existing
	DS-Lite mechanism.

A.1.2.  Has installation and initial setup been discussed?

	No, there are vague references to a provisioning mechanism and
	synchronization functionality that need to be set up.  See
	major open issue [2] above which calls out a missing normative
	reference that should address these topics.

A.1.3.  Has the migration path been discussed?

	No, but I suspect that this concern is inapplicable, as I think
	a carrier would not migrate from DS-Lite to lw4o6, but would
	deploy lw4o6 instead of DS-Lite.

A.1.4.  Have the Requirements on other protocols and functional
       components been discussed?

	Yes, but major open issue [1] is effectively in this area.

A.1.6.  Have suggestions for verifying correct operation been discussed?

	No, and they probably should be, as this protocol requires state
	synchronization among the lwB4, lwAFTR and the provisioning system,
	and is likely to exhibit problematic behavior if the relevant state
	information gets out of sync.

A.1.9.  Is configuration discussed?

	Yes, the draft does a good job of discussing what needs to be
	configured to set up the protocol (aside from state synchronization)
	and calling out protocol behavior aspects that should be configurable.

A.2 Management

	This is really not discussed, and in particular the lack of discussion
	of management information is notable because this protocol has a
	different operational structure than DS-Lite.  So, specifically:

 A.2.2.  Is management information discussed?

	No, this is minor open issue [3].  A sentence pointing to applicable
	MIB and/or YANG draft(s) would suffice to address this.

A.2.4.  Is configuration management discussed?

	Yes - the discussion is ok, even though specific configuration mechanisms
	are not discussed.

A.3.  Documentation

	The protocol does have significant operational impacts on the Internet.

	The shepherd's writeup indicates that multiple implementations exist
	among which interoperability has been tested.

David L. Black, Distinguished Engineer
EMC Corporation, 176 South St., Hopkinton, MA  01748
+1 (508) 293-7953             FAX: +1 (508) 293-7786 <at>        Mobile: +1 (978) 394-7754
Brian E Carpenter | 11 Oct 21:05 2014

Gen-ART telechatl review of draft-ietf-softwire-map-dhcp-09

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

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

Document: draft-ietf-softwire-map-dhcp-09.txt
Reviewer: Brian Carpenter
Review Date: 2014-10-12
IETF LC End Date: 2014-10-10
IESG Telechat date: 2014-10-16

Summary:   Ready


Thanks for the discussion and for dealing with my technical comments.
You may still need to discuss the number of listed authors with
the RFC Editor.
Meral Shirazipour | 11 Oct 00:00 2014

Gen-ART Telechat Call review of draft-ietf-oauth-saml2-bearer-21

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


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


Document: draft-ietf-oauth-saml2-bearer-21

Reviewer: Meral Shirazipour

Review Date: 2014-10-10

IETF LC End Date: 2014-09-29

IESG Telechat date: 2014-10-16




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



Nits/editorial comments:

Please see LC review :



Best Regards,



Meral Shirazipour



Gen-art mailing list
Gen-art <at>
Francis Dupont | 10 Oct 20:24 2014

second/independent view on draft-ietf-softwire-map-10.txt

I reviewed the draft-ietf-softwire-map-10.txt document but I was too
involved in Softwire stuff to be able to judge whether the text is
understable without prior knowledge. Can someone from the team look
at it and summary in the list?


Francis.Dupont <at>
Francis Dupont | 10 Oct 20:19 2014

review of draft-ietf-softwire-map-10.txt

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-softwire-map-10.txt
Reviewer: Francis Dupont
Review Date: 20141009
IETF LC End Date: 20141010
IESG Telechat date: 20141016

Summary: Ready

Major issues: None

Minor issues: None

Nits/editorial comments:
 First please note I participated to Softwire WG work so it is possible
the document is not understantable by someone who has no knowledge
about the topic. I'll ask another member of the gen-art team to look
at it to check this particular point.
Other comments:
 - there are more than 5 authors. RFC 7322 (the new RFC Style Guide)
  provides an accurate (i.e., more than previously) indication
  about this problem.

 - ToC page 2 and 13 page 20: Acknowledgements -> Acknowledgments

 - 1 page 3: (FYI comment): RFC 1933 automatic tunneling was
  historically the first way to run IPv6 (end of March 1995
  when IPv6 over Ethernet ran only at the July IETF meeting
  the same year). So in fact the RFC was published in 1996
  but the mechanism itself was implemented a year before...

 - 1 page 4: IMHO there is no need to expand the MAP abbrev
  at its first use because it is in the title (note this would
  not apply if it was in the Abstract).

 - 1 page 4: provider's(SP) -> provider's (SP)

 - 3 page 5: NAPT should be in the terminology, in particular
  because the standard abbrev is more NAT-PT

 - 3 page 5 and many other places: e.g. -> e.g., and i.e. -> i.e.,

 - 4 page 6: encapsulation/ -> encapsulation /

 - 4 page 7: figure 1 should be in one page (the RFC Editor should
  take care of this in his final editing).

 - 5 page 8: a missing closing parenthesis in "MAP BR (see Section 5.4."

 - 5.1 page 8: minimise -> minimize

 - 5.2 page 10: /prefix -> / prefix

 - 6 page 13: figure 8 in one page (cf figure 1)

 - 11 page 19: glitch in the text version:
  "Attacks facilitated by restricted port           set:"

 - 12 page 19 and 20, and Authors' Addresses page 32:
  CN is not a valid Country in a postal address, I suggest China
  or better P.R. China

 - A Example 3 page 25: please expand FMR in the example title.

 - A Example 5 page 26: avoid page break after a title

 - A Example 5 page 27 (twice): DHCP. -> DHCP

 - A Example 5 page 27: please expand BMR abbrev (i.e., make the text
  easier and more pleasant to read).


Francis.Dupont <at>