Brian E Carpenter | 12 Feb 01:23 2016
Picon

Gen-ART telechat review of draft-ietf-dnsop-edns-chain-query-06

I am the assigned Gen-ART reviewer for this draft. The General Area
Review Team (Gen-ART) reviews all IETF documents being processed
by the IESG for the IETF Chair. Please wait for direction from your
document shepherd or AD before posting a new version of the draft.

For more information, please see the FAQ at
<http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.

Document: draft-ietf-dnsop-edns-chain-query-06.txt
Reviewer: Brian Carpenter
Review Date: 2016-02-12
IETF LC End Date: 2016-01-18
IESG Telechat date: 2016-02-18

Summary: Ready
--------

Comment: Thanks for responding to my Last Call comments.
--------
Wassim Haddad | 12 Feb 00:09 2016
Picon

Gen-ART Review of draft-ietf-tram-stun-path-data-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>

Document: draft-ietf-tram-stun-path-data-03
Reviewer:  Wassim Haddad
Review Date: 11 February 2016
IETF LC End Date: 11 February 2016
IETF Telechat Date: unknown

Summary:  This draft is ready for publication as proposed RFC

- Major Issues: None

- Minor Issues: None

Question: Would it make sense to highlight the mobility case (since the document explicitly mentions 3G, 4G, WiFi) in which case, applying the described mechanism would suggest to the mobile to use a different interface after attaching to a different network… 


Regards,

Wassim H.

_______________________________________________
Gen-art mailing list
Gen-art <at> ietf.org
https://www.ietf.org/mailman/listinfo/gen-art
A. Jean Mahoney | 11 Feb 23:36 2016

Assignments for the 2016-02-18 Telechat

Hi all,

The following reviewers have assignments:

Reviewer           LC end     Draft
-------------------------------------------------------------------------
Brian Carpenter    2016-02-15 draft-ietf-dhc-anonymity-profile-06 **
Brian Carpenter    2016-01-18 draft-ietf-dnsop-edns-chain-query-06 *

Meral Shirazipour  2016-02-05 draft-ietf-lisp-eid-block-12 **

Peter Yee          2016-02-05 draft-ietf-lisp-eid-block-mgmnt-06 **
Peter Yee          2016-02-04 draft-ietf-dhc-dhcp-privacy-03 **

Russ Housley       2016-02-10 draft-ietf-i2rs-problem-statement-09 **
Russ Housley       2015-12-04 draft-ietf-eppext-tmch-smd-04 *

Robert Sparks      2016-02-04 draft-ietf-dhc-dhcpv6-privacy-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. The General Area
Review Team (Gen-ART) reviews all IETF documents being processed
by the IESG for the IETF Chair. Please wait for direction from your
document shepherd or AD before posting a new version of the draft.

For more information, please see the FAQ at

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

Document:
Reviewer:
Review Date:
IETF LC End Date:
IESG Telechat date: (if known)

Summary:

Major issues:

Minor issues:

Nits/editorial comments:
A. Jean Mahoney | 11 Feb 23:11 2016

A *new* batch of IETF LC reviews - 2016-02-11

Hi all,

The following reviewers have assignments:

Reviewer          LC end      Draft
---------------------------------------------------------------------
Elwyn Davies      2016-03-07  draft-wallace-est-alt-challenge-04

Fernando Gont     2016-02-22  draft-ietf-siprec-metadata-20

Francis Dupont    2016-02-24  draft-ietf-httpbis-alt-svc-12

Joel Halpern      2016-03-09  draft-martin-urn-globus-02

Jouni Korhonen    2016-03-09  draft-bao-v6ops-rfc6145bis-05

Suresh Krishnan   2016-02-22  draft-ietf-dane-openpgpkey-07 *

* 2nd LC

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 updated template is included below.

Thanks,

Jean

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

I am the assigned Gen-ART reviewer for this draft. The General Area
Review Team (Gen-ART) reviews all IETF documents being processed
by the IESG for the IETF Chair.  Please treat these comments just
like any other last call comments.

For more information, please see the FAQ at

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

Document:
Reviewer:
Review Date:
IETF LC End Date:
IESG Telechat date: (if known)

Summary:

Major issues:

Minor issues:

Nits/editorial comments:
Peter Yee | 5 Feb 11:01 2016

Gen-ART LC review of draft-ietf-dhc-dhcp-privacy-03

I am the assigned Gen-ART reviewer for this draft.  The General Area Review
Team (Gen-ART) reviews all IETF documents being processed by the IESG for
the IETF Chair.  Please treat these comments just like any other last call
comment.  For background on Gen-ART, please see the FAQ at
<http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>

Document: draft-ietf-dhc-dhcp-privacy-03
Reviewer: Peter Yee
Review Date: February 4, 2016
IETF LC End Date: February 4, 2016
IESG Telechat date: TBD

Summary: This draft is basically ready for publication as an Informational
RFC, but has nits and a minor issue that should be fixed/considered before
publication. [Ready with issues]

The draft describes privacy concerns arising from identifiers used in DHCP.
It doesn't not prescribe fixes for these concerns and the Security
Considerations are a little short.

Major issues: None

Minor issues: 

Page 9, section 5.6: the general concern with pervasive monitoring doesn't
necessarily arise from the operator but from an adversary who is able gather
information across a wide range of networks and develop correlations from
that information.  In many cases, a user has no true expectation of privacy
from the user's operator (ISP) and this may well be delineated in the terms
of service.  Consider beefing up this rather thin section.

Nits:

General: append a comma after each occurrence of "e.g."

General: consider if you should use the term "DHCP" or "DHCPv4".  They are
used somewhat interchangeably, but not consistently.  RFC 2131 doesn't use
the term DHCPv4, obviously.

General: idnits complains about the reference to RFC 2629.  I don't know if
you care or if it needs to be cited in the document or acknowledgements.

Page 2, section 1, 1st paragraph, 2nd sentence: delete "The" and "protocol".

Page 3, section 1, 1st full paragraph, 2nd sentence: change "It is" to
"These changes are".

Page 3, section 2, Stable identifier definition, 2nd sentence: delete "may".
Append a comma after "client-id".  Change "or" to "and".

Page 3, section 2, Stable identifier definition, 3rd sentence: change
"other" to "another".

Page 3, section 2, Stable identifier definition, 4th sentence: change
"identifier" to "identifiers".

Page 3, section 3, 1st paragraph, 1st sentence: change "which" to "that".
Insert "that" before "can be".  Delete "the" before "identification".

Page 3, section 3, 1st paragraph, 2nd sentence: insert "the" before
"identifiers".

Page 3, section 3, 1st paragraph, 3rd sentence: change "would be" to "are".

Page 4, section 3.1, 2nd paragraph, 6th sentence: change "document" to
"documents".

Page 4, section 3.1, 2nd paragraph, 9th sentence: delete "a" before
"non-volatile".

Page 4, section 3.1, 3rd paragraph, 2nd sentence: change "disabled" to "not
yet enabled".

Page 4, section 3.1, 3rd paragraph, 3rd sentence: insert "the" before
"client".  Delete the space after "link-".  Insert "it is" between "if" and
"being".

Page 4, section 3.2, 1st paragraph: insert "an" before "allocated".

Page 4, section 3.2, 3rd paragraph: insert "a" before "client".

Page 5, section 3.4, 2nd sentence: change "an option" to "options".

Page 5, section 3.5, 1st paragraph: append a comma after "Vendor Class
option".  Append "the" after "and".

Page 5, section 3.6, 1st sentence: delete "of the".  Delete before "DHCP
clients".

Page 6, section 3.7, 1st sentence: change "is" to "are".  Insert "a" before
"DHCP server".  Delete "the" after "provide".  Delete "the" before "DHCP
clients".

Page 6, section 3.7, 2nd sentence: change "It enables" to "They enable".

Page 6, section 3.8, 1st sentence: insert "a" before "DHCP client".

Page 6, section 3.9, 1st paragraph, 1st sentence: append "option" after
"Information".

Page 7, section 4.2, 1st paragraph, 2nd sentence: insert "a" before
"configured".

Page 7, section 4.2, 2nd paragraph, 2nd sentence: change "can be" into
"being".

Page 7, section 4.2, 2nd paragraph, 4th sentence: insert "an" before
"available".

Page 7, section 4.2, 3rd paragraph, 1st sentence: insert "the" before
"available".

Page 7, section 4.2, 3rd paragraph, 2nd sentence: insert "a" before
"returning".

Page 8, section 4.2, 1st partial paragraph, 2nd full sentence: append a
comma after "scanning".

Page 8, section 4.2, 1st partial paragraph, 3rd full sentence: insert "a"
before "much".

Page 8, section 4.2, 1st full paragraph, 1st sentence: insert a hyphen
between "identifier" and "based".

Page 8, section 4.2, 1st full paragraph, 2nd sentence: delete "being".

Page 8, section 4.2, 1st full paragraph, 4th sentence: insert "it" after
"e.g.,".  Change "reverted" to "reversed".

Page 8, section 4.2, 2nd full paragraph, 1st sentence: insert "an" before
"available".

Page 8, section 4.2, 2nd full paragraph, 3rd sentence: change "With the pool
allocation increasing" to "With increasing allocation from a pool".  Insert
"chance of a" before "collision".  Insert "the" before "birthday".

Page 8, section 4.2, 2nd full paragraph, 4th sentence: change "being" to
"are".  Change "most" to "more".  Change "resource" to "address".

Page 8, section 4.2, 2nd full paragraph, 6th sentence: insert "a" before
"privacy".  Append a comma after "vendor discovery attacks".

Page 8, section 4.2, 2nd full paragraph, 7th sentence: append "the" after
"e.g.,".  Change "can" to "may".  Insert "the" before "client-id".

Page 8, section 4.2, 2nd full paragraph: I will repeat Robert Sparks'
admonition on a similar paragraph in the DHCPv6 privacy draft: "the
paragraph on Random allocation comments on the poor performance of a
specific simplistic implementation of random selection. More efficient
algorithms exist. But the discussion is mostly irrelevant to the document.
Please simplify this paragraph to focus on the benefits of random
allocation."

Page 9, section 5.5, 2nd sentence: change "Option" to "option," (note the
comma too).  Change "options" to "option".  Insert a hyphen between "long"
and "lived".

Page 9, section 5.6, 1st sentence: insert "of the" before "aforementioned".

Page 9, section 5.6, 2nd sentence: change "operator" to "An operator".
Insert "a" before "non-trivial".  Change "observer" to "observe".  Insert
"the" before "client's".

Page 10, section 5.7, 1st sentence: append "a" after "put".  Append "the"
after "into".  

Page 10, section 5.7, 2nd-4th sentences: I'm not sure what a discussion of
Client ID is doing here in the discussion of discovering a client's IP
address or hostname.  Perhaps it belongs somewhere else?

Page 10, section 5.8, 2nd sentence: change "deducted" to "deduced".  Insert
"the" before "correlation".  Insert "of the" between "that" and
"identifier".  

Page 10, section 5.9, 1st sentence: insert "a" before "user".  And I'll let
slide the distinction between device and user for this discussion.

Page 10, section 5.9, 2nd sentence: insert "the" before "client's".  Append
"the" after "on" and change the immediately following "address" to
"addresses".  Insert "an" before "attacker" in the "active" part of the
sentence.  

Page 10, section 5.9, last sentence: change "owner" to "owner's".

Page 10, section 5.10, 1st sentence: change "as" to "to be".  Append "as a"
after "either".  Append "as a" after "or".  

Page 11, section 5.10, 1st paragraph, 1st sentence: insert "the" before the
first "DHCP".

Page 11, section 5.10, 2nd paragraph, 2nd sentence: insert "an" before
"operator's".  Insert "the" before "server's".

Page 11, section 6, 1st paragraph: delete the 2nd "the".

Page 11, section 6, 3rd sentence: change the second "for" to "to".

Page 11, section 7: change "at" to "in".

Page 11, section 9: append a comma after "Schaefer".

Page 12, normative references: I'm not sure why RFC 2136 is normative, yet
many of the options are informative.  I seem them as all being of the same
level.
A. Jean Mahoney | 5 Feb 00:11 2016

A *new* batch of IETF LC reviews - 2016-02-04

Hi all,

The following reviewers have assignments:

Reviewer          LC end      Draft
---------------------------------------------------------------------
Brian Carpenter   2016-02-15  draft-ietf-dhc-anonymity-profile-06

Christer Holmberg 2016-02-16  draft-ietf-netmod-opstate-reqs-04

Dan Romascanu  2016-02-16 draft-ietf-tsvwg-behave-requirements-update-06

Wassim Haddad    2016-02-11  draft-ietf-tram-stun-path-data-03

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 updated template is included below.

Thanks,

Jean

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

I am the assigned Gen-ART reviewer for this draft. The General Area
Review Team (Gen-ART) reviews all IETF documents being processed
by the IESG for the IETF Chair.  Please treat these comments just
like any other last call comments.

For more information, please see the FAQ at

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

Document:
Reviewer:
Review Date:
IETF LC End Date:
IESG Telechat date: (if known)

Summary:

Major issues:

Minor issues:

Nits/editorial comments:
Jouni Korhonen | 4 Feb 00:31 2016
Picon

Gen-ART review of draft-ietf-ecrit-held-routing-04

I am the assigned Gen-ART reviewer for this draft. The General Area 
Review Team (Gen-ART) reviews all IETF documents being processed by the 
IESG for the IETF Chair. Please wait for direction from your document 
shepherd or AD before posting a new version of the draft. For more 
information, please see the FAQ at <‚Äč 
http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.

- Jouni

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

Comments:

I do have little expertise on ECRIT topics in general so bear with me.

* The I-D gives IDnits errors and stuff and those must be corrected.
   Specifically those that concern the abstract, updating RFCs and such.

* Starting from Section 1 (Intro) most of the acronyms are not expanded
   on the first use.. or at all in the document. Revisit all acronyms
   including HELD, LoST etc and expand them on the first use.

* The sentence on line 185 (IDnits) took me a while to parse ;) Maybe
   some rewording would make it a bit more readable.

* There is no reference to "forest guide". I would expect to see one
   and at least a note that it is a special instance of a LoST server.

* In Section 4 URN is written multiple times as "urn".

* On line 290 s/PSAPS/PSAPs

* On lines 304 and 310 s/section/Section

* On line 462 s/Layer 7/layer-7

_______________________________________________
Gen-art mailing list
Gen-art <at> ietf.org
https://www.ietf.org/mailman/listinfo/gen-art
Suresh Krishnan | 3 Feb 06:04 2016
Picon

Gen-ART Telechat review of draft-ietf-ntp-extension-field-06

I am the assigned Gen-ART reviewer for this draft. The General Area
Review Team (Gen-ART) reviews all IETF documents being processed
by the IESG for the IETF Chair. Please wait for direction from your
document shepherd or AD before posting a new version of the draft.

For more information, please see the FAQ at
<http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.

Document: draft-ietf-ntp-extension-field-06.txt
Reviewer: Suresh Krishnan
Review Date: 2016-02-02
Telechat Date: 2016-02-04

Summary: This draft is almost ready for publication as a Proposed Standard
but has some issues that need to be addressed.

* Major

* Section 3

I could not find the text in RFC5905 Section 7.5 that this draft says it is
replacing. Specifically the following "OLD:" text does not exist in RFC5905

"
   In NTPv4, one or more extension fields can be inserted after the
   header and before the MAC, if a MAC is present. If a MAC is not
   present, one or more extension fields can be inserted after the
   header, according to the following rules:

   o  If the packet includes a single extension field, the length of the
      extension field MUST be at least 7 words, i.e., at least 28
      octets.

   o  If the packet includes more than one extension field, the length
      of the last extension field MUST be at least 28 octets. The length
      of the other extension fields in this case MUST be at least 16
      octets each.
"

After a bit of digging, I did find the verified Erratum #3627 that mentions
the text in RFC5905 being incorrect, but I am not sure the acceptance of the
Erratum implies that the "OLD" text in the RFC has been replaced.

* Minor

* Section 7.5.1.1

Not sure how the extension fields specify the use of MAC and the
corresponding algorithm. A reference would be good to have.

* Section 7.5.1.2

Why isn't there a corresponding sender rule for the different MAC algorithm
case that prevents the packet from ever being sent out and consuming bandwidth.

* Section 7.5.1.3

This sentence is hard to parse. Can you split/reword?

"  A MAC MUST NOT be longer than 24 octets if there is no extension
   field present unless through a previous exchange of packets with an
   extension field which defines the size and algorithm of the MAC
   transmitted in the packet and is agreed upon by both client and
   server."

Thanks
Suresh
Robert Sparks | 2 Feb 17:38 2016

Gen-ART LC review: draft-ietf-dhc-dhcpv6-privacy-03

I am the assigned Gen-ART reviewer for this draft. The General Area
Review Team (Gen-ART) reviews all IETF documents being processed
by the IESG for the IETF Chair.  Please treat these comments just
like any other last call comments.

For more information, please see the FAQ at

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

Document: draft-ietf-dhc-dhcpv6-privacy-03
Reviewer: Robert Sparks
Review Date: 2Feb2015
IETF LC End Date:4Feb2015
IESG Telechat date: Not yet scheduled

Summary: Ready with nits that should be addressed before publication

The reference to ietf-6man-ivp6-address-generation-privacy should be 
normative, and when this document is pointing to it because it is 
discussing a field carrying a generated address, it should be more 
explicit about why it's making the reference.

In section 4.3 the paragraph on Hash allocation should note that even a 
well implemented hash does not mitigate the threat of correlation over time.

In section 4.3, the paragraph on Random allocation comments on the poor 
performance of a specific simplistic implementation of random selection. 
More efficient algorithms exist. But the discussion is mostly irrelevant 
to the document. Please simplify this paragraph to focus on the benefits 
of random allocation.

Should section 5.3 also call out mapping IP addresses into geolocation?

Why doesn't section 5.5 also talk about things like MAC addresses?

Section 5.6 could probably borrow words from RFC7258 - it should at 
least reference it (currently there is only a reference from the 
introduction.)
Meral Shirazipour | 2 Feb 02:01 2016
Picon

Gen-ART Telechat Call review of draft-ietf-spring-problem-statement-06

I am the assigned Gen-ART reviewer for this draft. The General Area Review Team (Gen-ART) reviews all IETF documents being processed by the IESG for the IETF Chair. Please wait for direction from your document shepherd or AD before posting a new version of the draft.

 

For more information, please see the FAQ at  <http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.

 

Document: draft-ietf-spring-problem-statement-06

Reviewer: Meral Shirazipour

Review Date: 2016-01-05

IETF LC End Date: 2016-01-05 

IESG Telechat date: 2016-01-21, 2016-02-04

 

 

Summary: This draft is ready to be published as Informational RFC. But please see mailing list for ballot position comments.

 

 

Major issues:

 

Minor issues:

 

Nits/editorial comments:

-Please see last call review:http://www.ietf.org/mail-archive/web/gen-art/current/msg12796.html

 

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 | 1 Feb 15:36 2016
Picon

review of draft-mahesh-mef-urn-01.txt

I am the assigned Gen-ART reviewer for this draft. The General Area
Review Team (Gen-ART) reviews all IETF documents being processed
by the IESG for the IETF Chair.  Please treat these comments just
like any other last call comments.

For more information, please see the FAQ at

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

Document: draft-mahesh-mef-urn-01.txt
Reviewer: Francis Dupont
Review Date: 2016-01-25
IETF LC End Date: 2016-02-04
IESG Telechat date: 2016-02-04

Summary: Ready

Major issues: None

Minor issues: None

Nits/editorial comments:
 - I was first surpised there is no explanation about the MEF acronym
  but it is also the case on the Web site so IMHO it was Metro Etherner
  Forum at the beginning and it lost this meaning when it extended to
  Carrier Ethernet... So I have no concern about the lack of MEF expansion/
  introduction/etc.

 - 2 page 3: the RFC 3406 is not very clear about the value to put
  in the registration date. It seems you put the date of the first
  instance of the document. Anyway the IANA and/or the RFC Editor
  shall fix the date if needed...

 - Author's Address page 5: please add +1 in front of your phone number.
  (note this is the only action on your side)

Thanks

Francis.Dupont <at> fdupont.fr

PS: the document has been push on the IESG agenda since I read it.

Gmane