A. Jean Mahoney | 21 Aug 23:43 2014

A *new* batch of IETF LC reviews - 2014-08-21

Hi all,

The following reviewers have assignments:

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

Roni Even         2014-09-03   draft-ietf-jose-json-web-algorithms-31 *

Russ Housley      2014-09-03   draft-ietf-jose-json-web-signature-31 *

Scott Brim        2014-09-03   draft-ietf-jose-json-web-key-31 *

Suresh Krishnan   2014-09-03   draft-ietf-jose-json-web-encryption-31 *

Tom Taylor        2014-09-03   draft-ietf-oauth-json-web-token-25 *

Vijay Gurbani     2014-08-29   draft-ietf-6lo-ghc-03

Wassim Haddad     2014-09-01   draft-ietf-bfd-intervals-03

* The responsible AD said that these drafts could be assigned
   to individual reviewers. However, it may be useful to read
   draft-ietf-jose-json-web-algorithms first.

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

Peter Yee | 21 Aug 22:16 2014

Gen-ART Telechat review of draft-ietf-opsec-lla-only-10

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

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

Document: draft-ietf-opsec-lla-only-10
Reviewer: Peter Yee
Review Date: August-21-2014
IETF LC End Date: April-7-2014
IESG Telechat date: August-21-2014

Summary: This draft is basically ready for publication as an Informational
RFC, but has issues that should be fixed before publication. [Ready with
issues.]

This document discusses the (controversial) use of IPv6 link-local addresses
on router infrastructure links.  I don't find all of the (remaining)
arguments for use of link-local addresses to be terribly compelling, but I'm
not averse to the document's publication as a summary of some of the pros
and cons for those who desire to configure their routers in the manner
prescribed.  There may be other reasons that should be taken into
consideration, but I lack a network operator's experience to discuss them.

Minor:

Page 4, 5th paragraph, 2nd sentence: SSH brute force password attacks aren't
really reduced unless the reduction is simply not being able to attack a
single router over multiple interfaces in parallel.  A better scheme for
(Continue reading)

Suresh Krishnan | 21 Aug 07:27 2014
Picon

Gen-ART Early review of draft-brownlee-svg-rfc-07

I am the assigned Gen-ART reviewer for draft-brownlee-svg-rfc-07

For background on Gen-ART, please see the FAQ at
<http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html>.

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

Summary: This draft is on track to be published as an Informational RFC,
but I have some suggestions that the authors may like to consider.

* Meta comment

It is not clear how the SVGs will be included in the RFCs? Will they be
included as inline XML? Can you please clarify.

* Section 1

Last paragraph: It is not really true that diagrams in RFCs are not
normative. e.g. The ordering of fields in a packet is specified by a
packet format diagram and the text only describes the contents of the
fields (and not necessarily the structure of the packet itself). Is this
paragraph necessary?

* Section 4

Shouldn't we also be discussing the "role" attribute in the
accessibility context?

I also found that the Web Accessibility Initiative's ARIA primer to be a
good introduction in addition to the SVG-ARIA reference.
(Continue reading)

Scott Brim | 18 Aug 02:18 2014
Picon

Gen-Art telechat review of draft-ietf-karp-bfd-analysis

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

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

Document: draft-ietf-karp-bfd-analysis-06
Reviewer: Scott Brim
Review Date: 2014-08-17
IETF LC End Date: 2014-08-12
IESG Telechat date: 2014-08-21

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

Major issues:

Minor issues:

Nits/editorial comments:
Tom Taylor | 17 Aug 11:14 2014
Picon

Last Call review of draft-ietf-dnsop-rfc6304bis-04

It appears I messed up the distribution list. Please use the list in 
this E-mail for any replies.

Tom Taylor

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-dnsop-rfc6304bis-04
Reviewer: Tom Taylor
Review Date: 15 August 2014
IETF LC End Date: 29 July 2014
IESG Telechat date: (if known)

Summary: This draft is ready to go.

Major issues: none.

Minor issues: none.

Nits/editorial comments: none.
Tom Taylor | 16 Aug 00:58 2014
Picon

Last Call review of draft-ietf-dnsop-rfc6304bis-04

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-dnsop-rfc6304bis-04
Reviewer: Tom Taylor
Review Date: 15 August 2014
IETF LC End Date: 29 July 2014
IESG Telechat date: (if known)

Summary: This draft is ready to go.

Major issues: none.

Minor issues: none.

Nits/editorial comments: none.
Brian E Carpenter | 15 Aug 04:25 2014
Picon

Gen-ART telechat review of draft-ietf-tram-auth-problems-04

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

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

Document: draft-ietf-tram-auth-problems-04.txt
Reviewer: Brian Carpenter
Review Date: 2014-08-15
IETF LC End Date: 2014-08-08
IESG Telechat date: 2014-08-21

Summary:  Ready
--------

Comment:
--------

Thanks for addressing my previous comments.
Meral Shirazipour | 15 Aug 03:36 2014
Picon

Gen-ART Telechat Call review of draft-ietf-core-observe-14

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

 

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

 

Document: draft-ietf-core-observe-14

Reviewer: Meral Shirazipour

Review Date: 2014-08-08

IETF LC End Date: 2014-08-08

IESG Telechat date: 2014-08-21

 

Summary: This draft is ready to be published as Standard RFC.

 

Please see LC review: http://www.ietf.org/mail-archive/web/gen-art/current/msg10474.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
A. Jean Mahoney | 14 Aug 23:29 2014

Assignments for the 2014-08-21 Telechat

Hi all,

The following reviewers have assignments:

Reviewer            LC end       Draft
------------------------------------------------------------------------------------
Alexey Melnikov     2014-08-09   draft-ietf-l3vpn-pmsi-registry-05 *

Ben Campbell        2014-08-14   draft-ietf-core-groupcomm-21 **

Brian Carpenter     2014-08-08   draft-ietf-tram-auth-problems-04 *

Dan Romascanu       2014-07-16   draft-ietf-tictoc-security-requirements-11 *

Elwyn Davies        2014-08-07   draft-ietf-savi-dhcp-29 *

Joel Halpern        2014-08-08   draft-ietf-appsawg-json-merge-patch-06 **

Meral Shirazipour   2014-07-23   draft-ietf-tcpm-fastopen-09 **
Meral Shirazipour   2014-08-08   draft-ietf-core-observe-14 **

Peter Yee           2014-04-07   draft-ietf-opsec-lla-only-10 *

Roni Even           2014-07-29   draft-ietf-dnsop-as112-dname-04 **

Robert Sparks       2014-08-20   draft-ietf-paws-protocol-14 **

Scott Brim          2014-08-12   draft-ietf-karp-bfd-analysis-06 *

Tom Taylor          2014-07-29   draft-ietf-dnsop-rfc6304bis-04 *

* 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 | 14 Aug 23:23 2014

A *new* batch of IETF reviews - 2014-08-14

Hi all,

The following reviewers have assignments:

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

Peter Yee         2014-08-28   draft-ietf-roll-security-threats-09 *

Robert Sparks     2014-08-26   draft-ietf-tsvwg-rsvp-pcn-09

* 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 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:
Ben Campbell | 14 Aug 23:06 2014

Gen-ART LC Review of draft-ietf-core-groupcomm-21

(Oops, I screwed up the CC list the first try. Please send any replies to this distribution. Apologies for
the repeat.)

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-core-groupcomm-21
Reviewer: Ben Campbell
Review Date: 2014-08-14
IETF LC End Date: 2014-08-14
IESG Telechat date: 

Summary: This draft is not ready for publication as an informational RFC. It has some significant issues,
detailed below.

**** Major issues:

-- The draft contains significant material that I do not believe is appropriate for an informational RFC,
at least without some clear explanations about why it appears. It purports to clarify the normative stuff
in RFC 7252 concerning multicast, but it does quite a bit more than that.

Section 2.7 defines protocol, in the form of a RESTful methods and attributes to manage multicast group
membership.I agree in some cases it makes sense for an informational RFC to define protocol. A common
example is when we want to document a proprietary protocol for some reason. As written, this does not seem
to fall unto such a case. If the authors and working group believe it does, it would be helpful to add text
explaining that, and how the reader should interpret the section. (I recognize that this interface is
optional--but I don't think making it optional changes whether it should be standards track.)

In addition to that, the draft contains quite a bit of guidance that might be more appropriate BCP. For
example, there is guidance here where not following it might do harm to the network. Additionally, I don't
see how anyone could expect to achieve interoperability the multicast features of RFC 7252 without
understanding this draft.  (I have to wonder why RFC 7252 did not have a normative dependency on this draft.)

-- The security aspects of group CoAP are pretty bad. To its credit, the draft does a pretty good job of
calling that out, and that work is in progress to improve it. But I have to wonder if we would be better off not
encouraging multicast CoAP at all until such improvements are available. Section 5.3 calls out some
reasonable examples of mitigation approaches, but I am a little concerned at the guidance that one should
worry about these for "sensitive" or "safety-critical" data. People are not good at knowing what data is
"sensitive" until it gets used against them. I think this is especially true for IoT applications where we
have less deployment experience.

Along those lines, the Pervasive Monitoring Considerations section (kudos for having one, btw), tries to
balance application needs vs protecting information. But the smart-grid example seems to be a case where
the two are really at odds. I am afraid people will interpret this along the lines of "well, the smart-grid
application requirements force me to send unprotected data all over the place", when I think the right
answer is "Group CoAP should not be used for this sort of application until we can protect the data".

**** Minor issues:

-- 2.2, 5th paragraph: "For sending nodes, it is recommended to use the IP multicast address literal in a
group URI."

Can you elaborate on why? I can guess, but anytime we suggest using literal IP addresses rather than DNS
names, it's worth elaborating.

-- 2.4: " ... if the resource being POSTed to has been designed to cope with the unreliable and lossy nature of
IP multicast."

Can you elaborate on what it means to be "designed to cope..."? (Or reference something that does?)

-- 2.6:

I think the Resource Directory reference needs to be normative.  (I see the discussion of this from Barry's
AD review, where the authors argued that the reference is optional for implementations. But our
definition of normative references also includes things necessary to fully understand this draft.
Fully understanding even optional features is part of that.)

-- 2.7.1, 2nd paragraph:

Does this imply a need to coordinate pre-configured group addresses to avoid collisions?

-- 2.7.2.1: 2nd 2 last paragraph:

Are there any scenarios where a missing port might be determined from DNS, rather than just assuming the default?

-- 2.7.2.6, 1st paragraph: "This operation MUST only be used to delete or update group membership objects
for which the CoAP client, invoking this operation, is responsible"

Do I understand correctly that this replaces the entire set? Is it possible for two different clients to be
responsible for two different subsets? If so, how?

-- 2.8 and (especially) 2.9:

Lack of 2119 language in the "additional guidlines" seems inconsistent with other parts of this draft that
do use 2119 language. (I agree the places where you talk about what 7252 already says should not use 2119
language.) I can maybe see the difference for 2.8, but the congestion-avoidance stuff in 2.9 seems as
appropriate for 2119 language as most anything else in the draft.

(To be clear, I'm not suggesting more or less normative language--only consistency in its use.)

**** Nits/editorial comments:

-- Abstract:

Please expand CoAP on first use in abstract. (But don't remove the expansion in the body.)

-- 2.2, 4th paragraph: " ... it is recommended ..." 

Was that intended as normative? 

Along those lines, I see a number of sections where 2119 words are used in lower case where it looks like they
were not intended as normative (e.g., where you talk about normative requirements from RFC 7252), but in
other areas it's not as clear (like this one.) It would be best to either avoid lower case versions of 2119
words, or make it very clear whether they should be interpreted normatively or not.

-- 2.7.2, 2nd paragraph:

Wording is confusing. Do you mean MUST use the DTLS method, or MUST use some method, with DTLS an option?
Sentence seems to mean the former, in which it would be more clear to say "MUST use DTLS as described in ..."

-- 2.7.2.1, 3rd paragraph:

Please expand JDON on first use.

-- 2.7.2.1, paragraph after examples:

You mention an optional port for "a" attributes, but not for "n" attributes. The BNF for group-name seems to
allow an optional port. (and you mention an optional port for "n" later.

Gmane