Miguel A. Garcia | 3 Mar 16:52 2009
Picon

Gen-ART review of draft-ietf-lemonade-notifications-10.txt

I have been selected as the General Area Review Team (Gen-ART)
reviewer for this draft (for background on Gen-ART, please see
http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html).

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

Document: draft-ietf-lemonade-notifications-10.txt
Reviewer: Miguel Garcia <miguel.a.garcia <at> ericsson.com>
Review Date: 2009-03-03
IETF LC End Date: 2009-03-12
IESG Telechat date: (if known)

Summary: The document is ready for publication as an informational RFC.

Nits/editorial comments:

Since the document is a bit old, most of the references have been updated 
or even published as RFCs. Bear it in mind when the draft is handed to 
the RFC Editor.

/Miguel

--

-- 
Miguel A. Garcia
+34-91-339-3608
Ericsson Spain
Suresh Krishnan | 4 Mar 23:24 2009
Picon

Gen-ART review of draft-gulbrandsen-imap-response-codes-07.txt

I am the assigned Gen-ART reviewer for
draft-gulbrandsen-imap-response-codes-07.txt

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 Last Call comments
you may receive.

Summary: This draft is ready for publication as Proposed Standard.

Thanks
Suresh
McCann Peter-A001034 | 5 Mar 18:16 2009

Gen-ART review of draft-ietf-roll-indus-routing-reqs-04

I have been selected as the General Area Review Team (Gen-ART) reviewer
for this draft (for background on Gen-ART, please see
http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html).

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

Document: draft-ietf-roll-indus-routing-reqs-04.txt
Reviewer: Pete McCann
Review Date: 05 March 2009
IETF LC End Date: 05 March 2009
IESG Telechat date: unknown 

Summary: Ready but some editorial comments.  The draft provides an
         interesting overview of the particular problem domain of
         industrial control networks.

Major issues: 

Minor issues: 

The draft seems to contain a large number of run-on sentences.
Here is one I couldn't quite parse, from Section 8:

   Undecided yet is if these PDAs will use the LLN network directly to
   talk to field sensors, or if they will rather use other wireless
   connectivity that proxys back into the field, or to anywhere else,
   the user interfaces typically used for plant historians, asset
   management systems, and the likes.

(Continue reading)

Mary Barnes | 6 Mar 04:40 2009

A *new* batch of IETF LC reviews - 05 March 2009

Hi all,
 
Here's the link to the new LC assignments for this week:
http://www.softarmor.com/rai/temp-gen-art/reviewers-090305-lc.html

The assignments are captured in the spreadsheets:
http://www.softarmor.com/rai/temp-gen-art/gen-art.html
http://www.softarmor.com/rai/temp-gen-art/gen-art-by-reviewer.html

The standard template is included below.
Thanks,
Mary.

-------------------------------------------------------------------
I have been selected as the General Area Review Team (Gen-ART)
reviewer for this draft (for background on Gen-ART, please see
http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html).

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:









_______________________________________________
Gen-art mailing list
Gen-art <at> ietf.org
https://www.ietf.org/mailman/listinfo/gen-art
Mary Barnes | 6 Mar 04:43 2009

Assignments for 12 March 2009 Telechat

Hi all,

Here's the link to the summary of assignments for the March 12, 2009
telechat:
http://www.softarmor.com/rai/temp-gen-art/reviewers-090312.html

With the updated spreadsheets:
http://www.softarmor.com/rai/temp-gen-art/gen-art.html
http://www.softarmor.com/rai/temp-gen-art/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://www.alvestrand.no/ietf/gen/art/review-guidelines.html

Mary.

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

I have been selected as the General Area Review Team (Gen-ART)
reviewer for this draft (for background on Gen-ART, please see
http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html).

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

Document:
Reviewer:
Review Date: 
IESG Telechat date: 12 March 2009

Summary:

Major issues:
Minor issues:
Nits/editorial comments:
Miguel A. Garcia | 6 Mar 14:39 2009
Picon

Gen-ART review of draft-farrel-rtg-common-bnf-08.txt

I have been selected as the General Area Review Team (Gen-ART)
reviewer for this draft (for background on Gen-ART, please see
http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html).

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

Document: draft-farrel-rtg-common-bnf-08.txt
Reviewer: Miguel Garcia <miguel.a.garcia <at> ericsson.com>
Review Date: 2009-03-06
IESG Telechat date: 12 March 2009

Summary: This document is ready for publication as a standards track RFC

/Miguel

--

-- 
Miguel A. Garcia
+34-91-339-3608
Ericsson Spain
Miguel A. Garcia | 6 Mar 15:44 2009
Picon

Gen-ART review of draft-ietf-netlmm-pmipv6-heartbeat-05.txt

I have been selected as the General Area Review Team (Gen-ART)
reviewer for this draft (for background on Gen-ART, please see
http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html).

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

Document: draft-ietf-netlmm-pmipv6-heartbeat-05.txt
Reviewer: Miguel Garcia <miguel.a.garcia <at> ericsson.com>
Review Date: 2009-03-6
IESG Telechat date: 12 March 2009

Summary: This document is ready for publication as a standards track RFC.

I reviewed version -04 of this document, and all my comments have been 
properly addressed.

/Miguel
--

-- 
Miguel A. Garcia
+34-91-339-3608
Ericsson Spain
Spencer Dawkins | 6 Mar 18:44 2009

Gen-ART review of draft-ietf-netconf-tls-07.txt

Just to let people know - version 07 also looks fine to me ("ready for 
publication as a Proposed Standard").

Thanks,

Spencer

>I have been selected as the General Area Review Team (Gen-ART) reviewer for
> this draft (for background on Gen-ART, please see
> http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html).
>
> Please resolve these comments along with any other Last Call comments you 
> may receive.
>
> Document: draft-ietf-netconf-tls-06.txt
> Reviewer: Spencer Dawkins
> Review Date: 2009-02-09
> IETF LC End Date: 2009-02-19
> IESG Telechat date: (not known)
>
> Summary: This document is ready for publication as a Proposed Standard.
>
> Major issues: none noted
>
> Minor issues: none noted
>
> Nits/editorial comments: one noted (as follows)
>
> 2.2. Connection Closure
>
>   A TLS client (NETCONF manager) MUST close the associated TLS
>   connection if the connection is not expected to issues any NETCONF
>
> Spencer (nit): s/issues/issue/
>
>   RPC commands later.  It MUST send a TLS close_notify alert before
>   closing the connection.  The TLS client MAY choose to not wait for
>   the TLS server (NETCONF agent) close_notify alert and simply close
>   the connection, thus generating an incomplete close on the TLS server
>   side.  Once the TLS server gets a close_notify from the TLS client,
>   it MUST reply with a close_notify unless it becomes aware that the
>   connection has already been closed by the TLS client (e.g., the
>   closure was indicated by TCP).
>
>
>
> _______________________________________________
> Gen-art mailing list
> Gen-art <at> ietf.org
> https://www.ietf.org/mailman/listinfo/gen-art
> 
Robert Sparks | 6 Mar 21:01 2009

Genart review of draft-ietf-lemonade-profile-bis-07 (followup to -06)

I have been selected as the General Area Review Team (Gen-ART)
reviewer for this draft (for background on Gen-ART, please see
http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html).

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

Document: draft-ietf-lemonade-profile-bis-07
Reviewer: Robert Sparks
Review Date: 6 March 2009
IESG Telechat date: 12 March 2009

Summary: Ready for publication as Proposed Standard

All the comments below have been responded to.

The editor disagrees that any change is needed to address comments 2  
and 5 below.

I do not object to publishing this document without these changes, but  
still feel it would be an improvement. Please consider point 5 in  
particular.

RjS

On Feb 10, 2009, at 3:18 PM, Robert Sparks wrote:

> I have been selected as the General Area Review Team (Gen-ART)
>
> reviewer for this draft (for background on Gen-ART, please see
> http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html).
>
> Please resolve these comments along with any other Last Call comments
> you may receive.
>
> Document: draft-ietf-lemonade-profile-bis
> Reviewer: Robert Sparks
> Review Date: 10Feb09
> IETF LC End Date: 19Feb09
> IESG Telechat date: unknown
>
> Summary: Mostly ready but with nits to address
>
> 1) This is a bis, but has no Updates/Obsoletes indicator - How is  
> this intended to affect RFC 4550? (The string "4550" appears nowhere  
> in this draft btw).
>
> 2) It's not clear whether the Forward without Download section is  
> intended to be "Here's a couple of ways you can realize this feature  
> if you have all the tools this profile requires available to you" or  
> "If you are going to realize this feature, please do it this way" or  
> "You MUST choose one of these ways if you are going to realize this  
> feature". It would help to make the abstract, introduction, and the  
> first part of section 8 more explicit. Similarly, the draft is  
> registering a keyword to use in a CAPABILITY response - it would  
> help if the abstract and section 5.7.1 made this very explicit.
>
> 3) The 2nd paragraph of section 5.2 motivates sing the BINARY  
> extension. The last sentence implies "size" - it should explicitly  
> say that. I'm also not certain the "always" in the sentence is  
> actually true?
>
> 4) Section 5.3 first paragraph has language that will not age well.  
> Is the appeal to current thinking necessary for this text? Saying  
> something more like "SHOULD support DEFLATE ... for TLS .. to  
> facilitate compression at as low a level as possible" would avoid  
> it. More importantly, if the intent is that these extensions get  
> _used_ if available, this section should be more explicit.
>
> 5) Section 7 paragraph 2: Is this document attempting to restate  
> RFC4409 requirements or make new ones that are different? If its  
> just pointing out consequences of following 4409, I strongly  
> encourage you to rewrite this paragraph without using 2119 words.  
> For instance, "When following the requirements stated in [SUBMIT] a  
> client will either connect to an explicitly configured port at the  
> submission server, or will default first to 587. [SUBMIT] allows  
> subsequent attempts at other ports, including  25, if the initial  
> attempt fails. See [SUBMIT] for information on why using port 25 is  
> likely to fail ..."
>
> 6) (More a question that a comment) - Would the document benefit  
> from an explicit description of using $SubmitPending and $Submitted  
> during the description of putting the message only in the sent- 
> folder and using BURL when submitting it (at the end of section 8.6)?
>
> 7) Should you move the reference to 2821 forward?
>
> Nits:
>
> a) Section 4.1 paragraph 2 : Suggest either dropping the word "the"  
> or adding the word "extensions" to the end of the sentence.
>
> b) Suggest changing the sense of 3rd paragraph of section 4.4 -  
> something like "MUST expand all BURL parts before evaluating the  
> supplied message size".
>
> c) Section 5.4 first paragraph: "ransforms" should be "transforms"
>
> d) Its not clear by the "This section is non-normative" sentence is  
> needed - I suspect an earlier review comment caused it to happen. If  
> you really need to keep it, I suggest finding a way to restate it  
> such that a non-native-english reader wouldn't have to work hard to  
> know you meant 5.11 and not 5 by "This section".
>
> e) Its very hard to follow the transition from 8.3 to 8.4 - it would  
> be useful to have a "A new strategy" paragraph balancing the  
> "Traditional Strategy" section, followed by the "Step by step  
> description of the new strategy".
>
> f) In section 8.4.1, the examples go A0051, A0052, then A0054...  
> then A0053 appears later in the same flow (but at a different  
> server). If I'm not confused, these values really have no relation  
> with each other (other than not-equal), so there's not an error, but  
> you might be misleading implementers into thinking there should be  
> (cut-paste implementation of examples happens).
> _______________________________________________
> Gen-art mailing list
> Gen-art <at> ietf.org
> https://www.ietf.org/mailman/listinfo/gen-art
Spencer Dawkins | 6 Mar 23:29 2009

Gen-ART LC review of draft-ietf-lemonade-streaming-09

I have been selected as the General Area Review Team (Gen-ART)
reviewer for this draft (for background on Gen-ART, please see
http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html).
Please resolve these comments along with any other Last Call comments
you may receive.

Document: draft-ietf-lemonade-streaming-09
Reviewer: Spencer Dawkins
Review Date: 2009-03-06
IETF LC End Date: 2009-03-12
IESG Telechat date: (not known)

Summary: Almost ready for publication as Informational. A couple of nits 
(forwarded for the editor, not part of Gen-ART reviews), and a couple of 
minor questions.

Comments:

1.  Introduction

   Email clients on resource and/or network constrained devices, such as
   mobile phones, may have difficulties in retrieving and/or storing
   large attachments received in a message.  For example, on a poor
   network link, the latency required to download the entire attachment

Spencer (nit): s/attachment/attachment before displaying any of it/, 
perhaps? The sentence seems to say the user won't download the entire 
attachment under any conditions, but that's probably not what it should 
say...

   may not be acceptable to the user.  Conversely, even on a high-speed
   network, the device may not have enough storage space to secure the
   attachment once retrieved.

3.1.  Overview of Mechanism

   The proposed mechanism has the following steps:

   1.  Client determines from MIME headers of a particular message that
       a particular message part (attachment) should be streamed to the
       user.  Note that no assumptions are made about how/when/if the
       client contacts the user of the client about this decision.  User
       input MAY be required in order to initiate the proposed
       mechanism.

Spencer (minor): this MAY doesn't smell 2119 to me...

3.2.  Media Server Discovery

   There is also a scenario where media server discovery would improve
   the security of the streaming mechanism, by avoiding the use of
   completely anonymous URLs.  For example, the client could discover a
   media server address that was an authorised user of the IMAP server
   for streaming purposes, which would allow the client to generate a
   URL, which was secure in that it could *only* be accessed by an
   entity that is trusted by the IMAP Server to retrieve content.  The
   issue of trust in media servers is discussed more fully in Section 4

Spencer (nit): missing period after "4".

   Example values of the /shared/mediaServers METADATA entry:

   "<sip:ivr <at> ms.example.net:5060>:stream;<sip:annc <at> 
   ms1.example.net:5060>;<sips:ivr <at> ms2.example.net:5061>"

   "<sip:ivr <at> 192.0.2.40:5060>;<sip:192.0.2.41:5060>;<sips:annc <at> 
   192.0.2.42:5060>:stream"

Spencer (minor): Hmm. The paragraph that talked about line wrapping in 
section 2 was specifically about S: and C:, and that doesn't apply here. Is 
this clear enough for the target reader? At a minimum, I see people 
indenting continuation lines in other specs...

3.7.  Client Use of the Media Server MSCML IVR Service

   Since the playcollect request is used purely for its VCR
   capabilities, there is no need for the media server to perform DTMF
   collection, therefore the playcollect attributes "firstdigittimer",
   "interdigittimer" and "extradigittimer" SHOULD all be set to "0ms",
   which will have the effect of causing digit collection to cease
   immediately the media has finished playing.

Spencer (minor): "immediately the" is missing a word... if I could guess 
which word, this would be a nit.

3.8.  Media Server Use of IMAP Server

   If the media server is configured as an authorized user of the IMAP
   server, it SHOULD authenticate to the IMAP server using the
   credentials for that user.  This document does not go into the
   details of IMAP authentication, but the authentication SHOULD NOT use
   the LOGIN command over a non-encrypted communication path.

Spencer (minor, because I'm not your security reviewer): I'm struggling why 
this last statement is SHOULD NOT with no qualifications... if you tell me 
that this is normal practice in the e-mail community, I'll be quiet, but 
this would worry me if I saw it happening.

4.  Security Considerations

   o  However, since the media server will retrieve content from an IMAP
      server on the users behalf, the issue of security between the IMAP

Spencer (nit): s/users/user's/

      server and the media server also needs to be considered.  A client
      has no way of determining (programatically at least) the security
      of the exchanges between the media server and the IMAP server.
      However, it can determine, using the "stream" token that is part
      of the media server discovery mechanism described in Section 3.2,
      that the media server has a pre-existing authentication
      relationship with the IMAP server for the purposes of retrieving
      content using IMAP URLs.  The IMAP server administrator may put
      pre-requisites on media server administrator before this
      relationship can be established, for example to guarantee the
      security of the communication between the media server and the
      IMAP server.

From IDNits: (Yeah, I know my working group has pre-RFC5378 work, too..)

  Miscellaneous warnings:
  ----------------------------------------------------------------------------

  == The document seems to lack a disclaimer for pre-RFC5378 work, but was
     first submitted before 10 November 2008.  Should you add the 
disclaimer?
     (See the Legal Provisions document at
     http://trustee.ietf.org/license-info for more information.).

     trust-12-feb-2009 Section 6.c.iii text:
     "This document may contain material from IETF Documents or IETF
      Contributions published or made publicly available before November
      10, 2008.  The person(s) controlling the copyright in some of this
      material may not have granted the IETF Trust the right to allow
      modifications of such material outside the IETF Standards Process.
      Without obtaining an adequate license from the person(s)
      controlling the copyright in such materials, this document may not
      be modified outside the IETF Standards Process, and derivative
      works of it may not be created outside the IETF Standards Process,
      except to format it for publication as an RFC or to translate it
      into languages other than English."

  Checking references for intended status: Informational
  ----------------------------------------------------------------------------

  == Outdated reference: A later version (-01) exists of
     draft-ncook-urlauth-accessid-00

  == Outdated reference: draft-daboo-imap-annotatemore has been published as
     RFC 5464 

Gmane