review of draft-ietf-hokey-key-mgm-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 resolve these comments along with any other Last Call comments 
you may receive. 

Document: draft-ietf-hokey-key-mgm-08.txt
Reviewer: Francis Dupont
Review Date: 2009-07-30
IETF LC End Date: 2009-08-03
IESG Telechat date: unknown

Summary: Ready

Major issues: None

Minor issues:
 I understand this specification is very abstract about on wire entities
(for instance there is nothing about encoding, etc) but this can become
an issue about key labels, i.e., the reader has to read the (referenced)
RFC 5295 if (s)he wants to know what are exactly these key labels
(note the term "label" can denote many different things).
I suggest to be lightly more reader friendly, for instance by writing
the RFC 5295 establishes a IANA registry for "USRK Key Labels" too:
for the specification of key labels -> ... and associated IANA registry.

Nits/editorial comments:
 [Usual RFC Editor style stuff]

GEN-ART review of draft-ietf-alto-problem-statement-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-ietf-alto-problem-statement-02.txt
Reviewer: Sean Turner
Review Date: 2008-08-02
IETF LC End Date: 2009-08-04
IESG Telechat date: N/A

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

The one question in my mind is whether this should proceed now or remain 
a living document and become final at the end?  Is ALTO going to redo 
this document if they decide to expand their scope?

spt

Re: review of draft-ietf-simple-xcap-diff-13.txt

Sorry, for a slow response, just returned from vacation

On Thu, 2009-07-16 at 14:04 +0200, ext Francis Dupont 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-simple-xcap-diff-13.txt
> Reviewer: Francis Dupont
> Review Date: 2009-07-15
> IETF LC End Date: 3009-07-22
> IESG Telechat date: unknown
> 
> Summary: Ready
> 
> Major issues: None
> 
> Minor issues: None
> 
> Nits/editorial comments: 
>  - 3 page 6: i.e. -> i.e.,
>  - 3 pages 7 and 8: endoced -> encoded
>  - 4 pages 8-10: I am looking for a tool which can check the schema
>   (something like MIB doctor, I've tried XSV...)
>  - Authors' Addresses page 16: US -> USA
> 
fixed. Xerces and libxml2 can do some sanity checks, but certainly not

Re: GEN-ART review of draft-ietf-alto-problem-statement-02.txt

Thanks for the review.

Our plan was to publish the problem statement now, but let the  
requirements, which includes the taxonomy, be the living document,  
waiting for the bitter end...

On Aug 3, 2009, at 6:59 AM, Sean Turner 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-alto-problem-statement-02.txt
> Reviewer: Sean Turner
> Review Date: 2008-08-02
> IETF LC End Date: 2009-08-04
> IESG Telechat date: N/A
>
> Summary: This document is ready for publication as an Informational  
> RFC.
>
> The one question in my mind is whether this should proceed now or  
> remain a living document and become final at the end?  Is ALTO going  
> to redo this document if they decide to expand their scope?
>
> spt
>

Gen-ART Review of draft-ietf-dime-nai-routing-02

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-dime-nai-routing-02
Reviewer: Pete McCann
Review Date: 2009-08-03
IETF LC End Date: 2009-08-04
IESG Telechat date: unknown

Summary: Two major issues need discussion

Major issues:

The draft seems to address only routing of Request commands.  What
about Answers?  Are Diameter proxies required to re-write the
Origin-Realm and Origin-Host AVPs as the request gets routed?
Are they required then to maintain state to map the responses back
to the originating realm?  The processing rules seem to strip off
the decoration from the NAI; there might be a need for the home AAA
server to know the path that was taken through the network (routing
the Answer commands is only one possible reason).  Maybe the solution
is to provide a decorated Origin-Realm that is recomputed by each
hop.

> 4.2. Ensuring Backwards Compatibility
>

review: draft-ietf-dime-diameter-qos-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-dime-diameter-qos-10.txt
     Diameter Quality of Service Application
Reviewer: Joel M. Halpern
Review Date: 3-August-2009
IETF LC End Date: 4-August-2009
IESG Telechat date: N/A

Summary: This document is almost ready for publication as a Proposed 
Standard

Minor issues:  If I am understanding the message flows in section 4.2.1 
and 4.2.2 properly, the QAR which serves as a notification that QoS 
service is taking place (rather than as a request for authorization) 
uses "START" as a special indicator of this difference in usage.  I can 
not determine what this "START" indication actually is.  When I look at 
the ABNF in section 5.1 for the QAR, I can not determine where this 
indication would go.

In a related question, is there a reason that the data flows in section 
9 do not show this QAR(START...) message?

Nits/editorial comments:
Section 4.2.2 suggests that the AE may be able to dynamically discover 

review: draft-turner-clearancesponsor-attribute-01.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-turner-clearancesponsor-attribute-01.txt
     Clearance Sponsor Attribute
Reviewer: Joel M. Halpern
Review Date: 3-August-2009
IETF LC End Date: 14-August-2009
IESG Telechat date: N/A

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

Minor issues:  In trying to balance versatility and specificity, the 
introduction states that the attribute defined in this document may be 
used in X, Y, or "locations that support attributes."  Given that almost 
all our protocols support "attributes" for some meaning of the word, I 
think a somewhat better description is called for.  It may just suffice 
to say "locations or protocols that support ASN.1 definitions of 
attributes of entities which may conceptually have been cleared by (some 
suitable words)."  (Yes, I see that RFC 3281bis uses the same 
terminology.  It seems confusing to me.)

Nits/editorial comments:  Is it really true that world-wide clearances 
can always be sponsored by only one entity?  The restriction to one 
value seems to be a policy statement about a particular approach, so I 

review: draft-ietf-dime-diameter-qos-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-dime-diameter-qos-10.txt
     Diameter Quality of Service Application
Reviewer: Joel M. Halpern
Review Date: 3-August-2009
IETF LC End Date: 4-August-2009
IESG Telechat date: N/A

Summary: This document is almost ready for publication as a Proposed
Standard

Minor issues:  If I am understanding the message flows in section 4.2.1
and 4.2.2 properly, the QAR which serves as a notification that QoS
service is taking place (rather than as a request for authorization)
uses "START" as a special indicator of this difference in usage.  I can
not determine what this "START" indication actually is.  When I look at
the ABNF in section 5.1 for the QAR, I can not determine where this
indication would go.

In a related question, is there a reason that the data flows in section
9 do not show this QAR(START...) message?

Nits/editorial comments:
Section 4.2.2 suggests that the AE may be able to dynamically discover

Gen-ART LC review of draft-ietf-krb-wg-cross-problem-statement-04.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-krb-wg-cross-problem-statement-04.txt 
Reviewer: Brian Carpenter
Review Date: 2008-08-04
IETF LC End Date: 2009-08-11
IESG Telechat date: (if known)

Summary:  This draft is on the right track, but has open issues, described in the review.
--------

Major issues:
-------------

1) About 5.5.  Client's performance

>   It
>   takes 195 milliseconds to perform a TGS exchange with the on-board
>   H/W crypto engine.  Indeed, this result seems reasonable to the
>   requirement of the response time for the control network.  
    ...
>   Also, the delays
>   can grow to unacceptable delays when the number of intermediary
>   realms increases.

Re: review: draft-ietf-dime-diameter-qos-10.txt

Joel,

Thanks for review and comments. See inline...

The revised version will be uploaded if you are ok with the resolutions.

Regards,
Dong 

-----Original Message-----
From: Joel M. Halpern [mailto:jmh <at> joelhalpern.com] 
Sent: Monday, August 03, 2009 6:32 PM
To: Mary Barnes; General Area Review Team; draft-ietf-dime-diameter-qos <at> tools.ietf.org
Cc: vfajardo <at> tari.toshiba.com
Subject: [Gen-art] review: draft-ietf-dime-diameter-qos-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-dime-diameter-qos-10.txt
     Diameter Quality of Service Application
Reviewer: Joel M. Halpern
Review Date: 3-August-2009
IETF LC End Date: 4-August-2009
IESG Telechat date: N/A

Summary: This document is almost ready for publication as a Proposed Standard