A. Jean Mahoney | 20 Nov 23:23 2014

A *new* batch of IETF reviews - 2014-11-20

Hi all,

The following reviewers have assignments:

Reviewer          LC end       Draft
---------------------------------------------------------------------

Brian Carpenter   2014-12-04  draft-ietf-tcpm-accecn-reqs-07

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
(Continue reading)

Russ Housley | 20 Nov 00:54 2014

Gen-ART review of draft-ietf-tram-alpn-07

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-tram-alpn-07
Reviewer: Russ Housley
Review Date: 2014-11-19
IETF LC End Date: 2014-10-21
IESG Telechat date: 2014-11-25

Summary:  Ready

Major Concerns:  None

Minor Concerns:  None
Romascanu, Dan (Dan | 19 Nov 13:01 2014

Gen-ART review of draft-murdock-nato-nid-02.txt

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-murdock-nato-nid-02.txt

Reviewer: Dan Romascanu

Review Date: 11/19/14

IETF LC End Date: 11/19/14

IESG Telechat date: 11/25/14

 

Summary: Almost Ready

 

Major issues:

 

1.       The document does not expand the acronym NATO at the first occurrence. Moreover, in section 7 it mentions ‘that a standards body, like NATO’ which is misleading – as NATO is not a standards body. I suggest to use the full name in the title and abstract, expand the acronym at first occurrence and correct the text in Section 7.

2.       The abstract and introduction should make clear that this is a request made according to RFC 3406 for a formal URN space type, as described in Section 4.3 of RFC 3406.

3.       As per RFC 3406, section 4.3:

 

Ø     The proposed template

Ø     should be sent to the:

Ø 

 

Ø        urn-nid <at> apps.ietf.org

Ø     mailing list to allow for a two week discussion period for clarifying

Ø     the expression of the registration information, before the IESG

Ø     reviews the document.

Ø   

 

I could not find in the summary written by the AD shepherd an indication whether this review occurred.

 

Minor issues:

 

Nits/editorial comments:

 

 

 

_______________________________________________
Gen-art mailing list
Gen-art <at> ietf.org
https://www.ietf.org/mailman/listinfo/gen-art
Christer Holmberg | 18 Nov 00:46 2014
Picon

Gen-ART review of draft-ietf-softwire-4rd-09.txt

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-softwire-4rd-09.txt

 

Reviewer:                      Christer Holmberg

 

Review Date:                   18 November 2014

 

IETF LC End Date:              10 October 2014

 

IETF Telechat Date:            30 October 2014

 

Summary:                       My comments and issues on the previous version have been addressed, and the document is now ready for publication.

 

Major Issues: None

 

Minor Issues: None

 

Editorial nits: None

 

_______________________________________________
Gen-art mailing list
Gen-art <at> ietf.org
https://www.ietf.org/mailman/listinfo/gen-art
A. Jean Mahoney | 18 Nov 00:05 2014

Assignments for the 2014-11-25 Telechat

Hi all,

       NOTE: This upcoming telechat falls on Tuesday next week.
             Please provide reviews before then. Thanks!

The following reviewers have assignments:

Reviewer            LC end       Draft
------------------------------------------------------------------------------------
Alexey Melnikov     2014-11-03 draft-ietf-mpls-pim-sm-over-mldp-02
Alexey Melnikov     2014-08-13 draft-ietf-rmcat-cc-requirements-08 *

Ben Campbell        2014-11-03 
draft-ietf-mpls-deprecate-bgp-entropy-label-01 **

Christer Holmberg   2014-11-18   draft-kucherawy-rfc3777bis-03

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

Dan Romascanu       2014-11-19   draft-murdock-nato-nid-02

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-03 *
Francis Dupont      2014-11-06 draft-ietf-opsawg-mibs-to-ieee80231-01 **

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

Martin Thomson      2014-11-18 draft-dukhovni-opportunistic-security-05 **
Martin Thomson      2014-10-27   draft-ietf-manet-ibs-03 **

Roni Even           2014-10-08   draft-ietf-dnsop-as112-dname-04 **
Roni Even           2014-10-30 draft-leiba-cotton-iana-5226bis-11 *

Russ Housley        2014-10-21   draft-ietf-tram-alpn-07 *

Robert Sparks       2014-10-27 draft-ietf-pce-wson-routing-wavelength-15 *

Vijay Gurbani       2014-11-03 draft-ietf-manet-nhdp-optimization-03

* 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 | 17 Nov 23:53 2014

A *new* batch of IETF LC reviews - 2014-11-17

Hi all,

The following reviewers have assignments:

Reviewer          LC end       Draft
---------------------------------------------------------------------

Alexey Melnikov   2014-12-01   draft-ietf-grow-irr-routing-policy-considerations-05

Ben Campbell      2014-12-01   draft-ietf-opsec-dhcpv6-shield-04

Tom Taylor        2014-12-01   draft-ietf-tsvwg-sctp-prpolicies-05

Vijay Gurbani     2014-11-28   draft-ietf-jose-cookbook-06

Wassim Haddad     2014-12-01   draft-ietf-eman-applicability-statement-08

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:
Black, David | 12 Nov 23:48 2014

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

The -12 draft responds to all the concerns expressed in the Gen-ART and
OPS-Dir review of the -10 version.

Here are some notes on some significant resolutions to concerns:

- DHCPv6 based configuration using OPTION_S46_CONT_LW is now mandatory
to implement (MUST) instead of strongly recommended (SHOULD).

- Information synchronization between the provisioning mechanism and the
lwAFTR is now out of scope (was previously promised in a non-existent
companion document).

- Management of this protocol will be taken up by the WG, but is not
yet far enough along that it makes sense to include references to
any drafts here.

Many thanks to the authors for dealing with the significant number
of changes that resulted from this review.

Thanks,
--David

> -----Original Message-----
> From: Black, David
> Sent: Saturday, October 11, 2014 6:30 PM
> To: yong <at> csnet1.cs.tsinghua.edu.cn; sunqiong <at> ctbri.com.cn;
> mohamed.boucadair <at> orange.com; tena <at> huawei.com; yiu_lee <at> cable.comcast.com;
> ian.farrer <at> telekom.de; General Area Review Team (gen-art <at> ietf.org); ops-
> dir <at> ietf.org
> Cc: ietf <at> ietf.org; softwires <at> ietf.org; Black, David
> Subject: 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:
> 
> <http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.
> 
> 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
> NAPT.
> 
> 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:
> 
> http://www.iana.org/assignments/service-names-port-numbers/service-names-port-
> numbers.xhtml
> 
> 
> [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
>    configurable.
> 
> 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:
> 
> OLD
>    Additionally, the lwAFTR MAY implement:
> 
>    o  Discarding of all inbound ICMP messages.
> NEW
>    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]
>    address.
> 
> 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 192.0.0.0/29" 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
>      draft-ietf-softwire-map-dhcp-07
> 
>   == Outdated reference: draft-ietf-dhc-dhcpv4-over-dhcpv6 has been published
>      as RFC 7341
> 
>   == Outdated reference: A later version (-06) exists of
>      draft-ietf-pcp-port-set-05
> 
> --- 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.
> 
> Thanks,
> --David
> ----------------------------------------------------
> David L. Black, Distinguished Engineer
> EMC Corporation, 176 South St., Hopkinton, MA  01748
> +1 (508) 293-7953             FAX: +1 (508) 293-7786
> david.black <at> emc.com        Mobile: +1 (978) 394-7754
> ----------------------------------------------------
Elwyn Davies | 12 Nov 23:27 2014

Gen-art LC review of draft-ietf-nfsv4-rfc3530bis-dot-x-22

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-rfc3530bis-dot-x-22.txt
Reviewer: Elwyn Davies
Review Date: 2014-11-12
IETF LC End Date: 2014-10-06
IESG Telechat date: 2014-12-04

Summary:
The main aims of this review were to
1. Check that the extracted .x file actually compiled (it didn't) - fix 
below.
2. To check the text corresponded with draft-ietf-nfsv4-rfc3530bis-33/34

I found a few minor glitches but otherwise this draft is almost ready.

Major Issues:
(well not really major)
The extracted .x file does not currently compile with rpcgen.
The cause is the definition of linktext4 (at line 154 of the extracted 
file) which was just fixed in draft-ietf-nfsv4-rfc3530bis-34 but not in 
this one.
s/linktext4/linktext4<>/

Minor Issues:

The type used for the lease_time attribute in -dot-x-22 is uint32_t, i.e.,
typedef uint32_t fattr4_lease_time;
In 3530bis the type shown in Table 2 is nfs_lease4 but there is no 
mapping from this type to a base integer type in either document.  This 
needs cleaning up.

========================

Differences between rfc3530-33/34 and rfc35230bus-dot-x-22:
-----------------------------------------------------------

The items below need fixing up in 3530bis (apart from possibly the 
lease_time type) to make them consistent with -dot-x-22.

- Error codes NFS4ERR_CB_PATH_DOWN and NFS4ERR_SHARE_DENIED are missing 
from table 5 in rfc3530-33 and there are no corresponding sections in 
Section 13.1.1 of rfc3530-33.  However, they are mentioned in the text 
and in Tables 6 and 8.  BTW All these tables ought to have titles 
(assuming they remain after Barry's comments).  Also the ordering in 
Table 5 is slightly out of dictionary sort order if anyone cares.

- Required attributes (Table 2 in rfc3530bis):
   + change attribute type s/b changeid4
   + lease_time attribute the type used in -dot-x is uint32_t -
     nfs_lease4 used in 3530bis-33 is not defined in dot-x or copied
     into 3530bis.
   + fs_locations attribute type s/b fs_locations4 (not fs_locations)
   + owner attribute type s/b utf8str_mixed (not utf8<>)
   + owner_group attribute type s/b utf8str_mixed (not utf8<>)
Russ Housley | 9 Nov 23:41 2014

Gen-ART review of draft-ietf-ccamp-rwa-info-22.txt

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-ccamp-rwa-info-22
Reviewer: Russ Housley
Review Date: 2014-11-09
IETF LC End Date: 2014-11-27
IESG Telechat date: unknown

Summary: Almost ready; a few minor things to clear up.

Major Concerns:

None.

Minor Concerns:

In section 3, please add a sentence or two that explains switching
subsystem and line subsystem.  The definitions might be best appear in
Section 2.  I checked in RFC 6163, but I did not find a description of
these terms there.  

Other Comments:

Section 1 begins with:

   The purpose of the following information model for WSONs ... 

In my opinion, it would be better to say something like:

   The purpose of the WSONs information model described in this
   document ...

Likewise, in section 3, it says:

   The following WSON RWA information model ...

In my opinion, it would be better to say something like:

   The WSON RWA information model in this document ...

In section 5.1, 3rd paragraph, it says:

   ... Since not all input ports
   can necessarily reach each resource block, the model starts with a
   resource pool input matrix RI(i,p) = {0,1} whether input port i can
   reach potentially reach resource block p.

s/reach potentially reach/potentially reach/
Meral Shirazipour | 8 Nov 02:17 2014
Picon

Gen-ART Last Call review of draft-ietf-opsawg-capwap-hybridmac-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-opsawg-capwap-hybridmac-06

Reviewer: Meral Shirazipour

Review Date: 2014-11-07

IETF LC End Date:  2014-11-10

IESG Telechat date: NA

 

 

Summary:

This draft is ready to be published as Standards Track RFC but I have some editorial comments .

 

 

Nits/editorial comments:

-[Page 1], Abstract, suggestion: please spell out CAPWAP: "Control And Provisioning of Wireless Access Points (CAPWAP)"

-[Page 1], Abstract, suggestion: "However, in the split MAC mode," ----> use "Split" instead of "split" (to review the rest of draft)

-[Page 1], Abstract, remove double occurrence of "clearly": in "...not been clearly clearly defined"

Also correct:

"functions are not been clearly clearly defined"----->"functions have not been clearly defined" or "functions are not clearly defined"

 

 

Best Regards,

Meral

---

Meral Shirazipour

Ericsson

Research

www.ericsson.com

_______________________________________________
Gen-art mailing list
Gen-art <at> ietf.org
https://www.ietf.org/mailman/listinfo/gen-art
Francis Dupont | 7 Nov 10:18 2014
Picon

review of draft-ietf-opsawg-mibs-to-ieee80231-01.txt

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-opsawg-mibs-to-ieee80231-01.txt
Reviewer: Francis Dupont
Review Date: 20141104
IETF LC End Date: 20141106
IESG Telechat date: 20141125

Summary: Ready

Major issues: None

Minor issues: None

Nits/editorial comments:
 - ToC page 2 and 7 page 5: Acknowledgements -> Acknowledgments
  (BTW what is the favorite spelling in Canada: UK or US one?)

Regards

Francis.Dupont <at> fdupont.fr

Gmane