Gen-ART review for draft-ietf-ipfix-file-03.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-ipfix-file-03.txt
Reviewer: Vijay K. Gurbani
Review Date: Apr 1, 2009
IESG Telechat date: Apr 3, 2009

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

The draft has 0 major issues, 0 minor issues, and 0 Nits/Editorial
comments.

Thanks,

- vijay
--

-- 
Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent
1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60566 (USA)
Email: vkg <at> {alcatel-lucent.com,bell-labs.com,acm.org}
WWW:   http://www.alcatel-lucent.com/bell-labs

_______________________________________________
Gen-art mailing list
Gen-art <at> ietf.org

Gen-ART LC review of draft-ietf-ipfix-mib-06.txt

gmane.ietf.gen-art

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-ipfix-mib-06.txt
Reviewer: Brian Carpenter
Review Date: 2009-04-02
IETF LC End Date: 2009-04-03
IESG Telechat date: (if known)

Summary:  Ready
--------

Comments: 
--------- 

The technical description is clear and did not raise any questions in my
mind. I did not check the MIB module in detail.


Editorial issues:
-----------------

I question whether this document really needs the pre-5378
disclaimer ("This document may contain material from IETF Documents
or IETF Contributions published or made publicly available before

Gen-ART Review of draft-ietf-softwire-security-requirements-07

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-softwire-security-requirements-07
Reviewer..........:  Christian Vogt
Review date.......:  2009-04-01 (no, not a joke)
IESG Telechat date:  2009-04-02

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

The document analyzes potential security issues and resulting security
requirements for scenarios where softwire methods are used for IPv4/IPv6
co-existence.  I think this type of analysis is important given the
expected widespread existence of these scenarios.  Below are a few
recommended modifications that should be applied to the document prior
to publication:

- The document is partly about the security for data packets, and it
   concludes by requiring authentication, integrity, and reply
   protection for data packets.  Why should this be a requirement given
   that the purpose of softwires is simply to provide interworking
   between IPv4 and IPv6?  Certainly, there will be /some/ scenarios
   where one would want data packet protection, but generally such
   protection would be independent of the use of IPv4/IPv6 co-existence

Gen-ART review of draft-thomson-beep-async-02.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-thomson-beep-async-02.txt
Reviewer: Miguel Garcia
Review Date: 02-April-209
IETF LC End Date: 24-April-2009

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

The document is clear. There are no identified issues.

/Miguel

--

-- 
Miguel A. Garcia
+34-91-339-3608
Ericsson Spain

Re: Gen-ART Review of draft-ietf-softwire-security-requirements-07

Hello Christian;
Thank you for reviewing the document and comments.
We will shorly update the document but wait for posting it.

Shu Yamamoto
>
> 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-softwire-security-requirements-07
> Reviewer..........:  Christian Vogt
> Review date.......:  2009-04-01 (no, not a joke)
> IESG Telechat date:  2009-04-02
>
>
> Summary:  This draft is basically ready for publication, but has nits
>           that should be fixed before publication.
>
> The document analyzes potential security issues and resulting security
> requirements for scenarios where softwire methods are used for IPv4/IPv6
> co-existence.  I think this type of analysis is important given the
> expected widespread existence of these scenarios.  Below are a few
> recommended modifications that should be applied to the document prior
> to publication:
>

Assignments for April 9, 2009 Telechat

_______________________________________________
Gen-art mailing list
Gen-art <at> ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

A *new* batch of IETF LC reviews - 2 April 2009

Hi all,

Here's the link to the new LC assignments for this week: 
http://www.softarmor.com/rai/temp-gen-art/reviewers-090402-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 review of draft-ietf-pce-global-concurrent-optimization-10

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-pce-global-concurrent-optimization-10
Reviewer: David L. Black
Review Date: April 3, 2009
IESG Telechat date: April 9, 2009

Summary:

This draft is basically ready for publication, but has nits
that should be fixed before publication.

Comments:

The -10 draft addresses all of the points noted in the
Gen-ART review of the -08 version.  Unfortunately,
idnits 2.11.08 found a few things to complain about:

  ** You're using the IETF Trust Provisions Section 6.b License Notice
from
     10 Nov 2008 rather than the newer Notice from 12 Feb 2009, which is
     required now.  (See http://trustee.ietf.org/license-info/)

  ** There are 3 instances of too long lines in the document, the
longest one
     being 2 characters in excess of 72.

  == 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.).

  == Missing Reference: 'PCEP' is mentioned on line 565, but not defined

The RFC Editor can take care of the "too long lines" item,
but the other three items need attention.

Thanks,
--David
----------------------------------------------------
David L. Black, Distinguished Engineer
EMC Corporation, 176 South St., Hopkinton, MA  01748
+1 (508) 293-7953             FAX: +1 (508) 293-7786
black_david <at> emc.com        Mobile: +1 (978) 394-7754
----------------------------------------------------

Gen-ART review of draft-ietf-kitten-gssapi-channel-bindings-06.txt

gmane.ietf.gen-art

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-kitten-gssapi-channel-bindings-06.txt
Reviewer: Brian Carpenter
Review Date: 2009-04-05
IESG Telechat date: 2009-04-09

Summary: Almost ready; needs one clarification.

Comments: 

I was expecting the sentence quoted below to be updated
following Nico's comments on my Last Call comment. I think the new
text would be

    Where the language binding of the GSS-API model's channel bindings is as 
    single OCTET STRINGs (or the language's equivalent), then the implementation
    SHOULD assume that the given bindings correspond only to the
    application-data field of GSS-CHANNEL-BINDINGS as shown above.


On 2008-11-03 21:47, Nicolas Williams wrote:
> On Mon, Nov 03, 2008 at 11:10:20AM +1300, Brian E Carpenter wrote:

...

>> I can't parse this sentence:
>>
>>    Where a language binding of the GSS-API models channel bindings as
>>    OCTET STRINGs (or the language's equivalent), then the implementation
>>    MUST assume that the given bindings correspond only to the
>>    application-data field of GSS-CHANNEL-BINDINGS as shown above, rather
>>    than some encoding of GSS-CHANNEL-BINDINGS.
>>
>> 1. Is the 'as' supposed to mean 'only as'? 
> 
> More like "as a single OCTET STRING".
> 
>> 2. Why is this restricted to the application-data field? Why doesn't
>> it also cover the various address fields? (OK, there's a clue hidden
>> in the Security Considerations, but the explanation belongs here.)
> 
> Because RFC2743 said "OCTET STRING" and later RFC2744 imposed structure
> without specifying an encoding of that structure to an OCTET STRING.
> 
> That's an old screwup.
> 
> Now, if anyone had built a language binding based strictly on RFC2743
> then they'd have only an OCTET STRING input.  What to do?  Well, since
> those "network addresses" in the RFC2744 channel binding structure
> turned out to be utterly useless[*] and since such a language binding
> would not have intended for network-addresses-as-channel-bindings, the
> simplest choice is as given above.
> 
>> 3. Maybe I'm lacking context, but the 'rather than' clause doesn't make 
>> sense to me at all. 
> 
> I think it can be removed.  Also, I suppose the MUST should be a SHOULD.
> 

_______________________________________________
Gen-art mailing list
Gen-art <at> ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

review of draft-iana-rfc3330bis-06.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-iana-rfc3330bis-06.txt
Reviewer: Francis Dupont
Review Date: 2009-04-03
IETF LC End Date: 2009-04-18
IESG Telechat date: unknown

Summary: Ready

Major issues: None

Minor issues: None

Nits/editorial comments: 
 I have two concerns about the Abstract:
  - the first sentence "This document obsoletes RFC 3330." should be removed
   before the publication as an RFC
  - the last sentence has an explicit reference to RFC 5156, this could be
   considered as forbidden in an Abstract, I propose to change it into:
   ... are described in another document (RFC 5156).

 In authors' addresses: United States -> United States of America
 (there is an incredible amount of countries with a full name translating
  into united states in English .

Regards

Francis.Dupont <at> fdupont.fr