headers
Elwyn Davies | 2 Feb 14:09

Gen-art review of draft-ietf-dime-pmip6-lr-07

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-dime-pmip6-lr-07.txt
Reviewer: Elwyn Davies
Review Date: 2 February 2012
IETF LC End Date: 24 January 2012
IESG Telechat date: 16 February 2012

Summary:
I have a couple of queries/minor issues regarding checking whether LMA1
and LMA2 are the same node and some hand waving over the idea of
'localized routing setup/signaliing'.  There are also a few minor nits.
Otherwise this is ready for the IESG.

[This document missed the normal gen-art last call allocation
notification mechanism for some reason - so I didn't realize it was on
my allocation till the end of last call and as a result the review is a
bit late.]

Major issues:
None

Minor issues:
s5.1, para 3 and s5.2, last para:
In s5.1:
(Continue reading)

Permalink | Reply | 0 comments |
headers
kathleen.moriarty | 2 Feb 15:15

Gen-ART review for draft-kucherawy-authres-spf-erratum-01

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-kucherawy-authres-spf-erratum-01
Reviewer: Kathleen Moriarty
Review Date: 2012-02-02
IETF LC End Date: 2012-02-03
IESG Telechat date: (if known)

Summary:  This draft is ready for publication.
   This memo updates the registry of authentication method results in
   Authentication-Results: message header fields, correcting a
   discontinuity between the original registry creation and the SPF
   specification.

Major issues:

Minor issues:

Nits/editorial comments:
_______________________________________________
Gen-art mailing list
Gen-art <at> ietf.org<mailto:Gen-art <at> ietf.org>
https://www.ietf.org/mailman/listinfo/gen-art
Permalink | Reply | 0 comments |
headers
Miguel A. Garcia | 2 Feb 15:51
Picon
Favicon

Gen-ART review of draft-ietf-hokey-erp-aak-07

I have been selected as the General Area Review Team (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 comments you may receive.

Document: draft-ietf-hokey-erp-aak-07
Reviewer: Miguel Garcia <miguel.a.garcia <at> ericsson.com>
Review Date: 2011-01-02
IETF LC End Date: 2012-02-07

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

Major issues:

- None

Minor issues:

- The main problem I have with this draft is the lack of normative text 
(RFC 2119 reserved words) in relevant paragraphs. If interoperability is 
to be granted, an effort should be taken in adding quite a few more 
normative statements.

However, having said that, the section where I find more that there 
should be more normative text, is Section 3, which is an "Overview" 
section. In general, an overview section should use descriptive, but not 
normative text.
(Continue reading)

Permalink | Reply | 5 comments |
headers
Jeff Downs | 2 Feb 19:56

Re: Gen-ART review of draft-ietf-payload-rtp-klv-02

Richard and all:

I am one of the co-authors of the above named draft.  Thank you for the 
review and comments on the draft.

After discussion with the document shepherd and the WG co-chair, we 
decided to incorporate some of the suggested changes into a new revision 
(-03) of the draft.  This new revision was uploaded to the IETF 
datatracker yesterday and is available now:
http://tools.ietf.org/html/draft-ietf-payload-rtp-klv-03

Please see below for specifics on how each of the Gen-ART comments were 
addressed.

Again, thank you for the review and comments.

Jeff Downs
PAR Government Systems

On 1/26/2012 4:11 PM, Richard L. Barnes wrote:
 > ===== MINOR =====
 >
 > Section 6.1.: Given that the KLV format can carry a variety of data
 > types, would it be helpful for this type to have one or more
 > parameters to describe what types of KLVs might be in the stream?

The widely varied nature and use cases of this format do not lend very 
well to specific parametrization describing the data. KLV, by its very 
nature, is self-identifying through the use of universally unique keys.
No changes were made to the draft in this regard.
(Continue reading)

Permalink | Reply | 0 comments |
headers
A. Jean Mahoney | 2 Feb 23:43
Favicon

A *new* batch of IETF LC reviews - 2012-02-02

Hi all,

Here's the link to the new LC assignments:
http://wiki.tools.ietf.org/dav/genart/reviewers-120202-lc.html

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

And I have made the assignments in the review tool:
http://art.tools.ietf.org/tools/art/genart/

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

Permalink | Reply | 0 comments |
headers
Miguel A. Garcia | 3 Feb 08:18
Picon
Favicon

Re: Gen-ART review of draft-ietf-hokey-erp-aak-07

Zhen,

The issue with IANA is double:

On one side, you need to clearly indicate to IANA which registry they 
need to change.

On another side, someone reading this RFC should be able to go to 
www.iana.org and find the registry.

The solve both issues you don't need a reference to RFC 5295. What you 
need to say "Extended Master Session Key (EMSK) Parameters registry" in 
the IANA considerations section, because this is the official name by 
which the registry is known.

BR,

          Miguel

On 03/02/2012 8:11, Zhen Cao wrote:
>> >
>> >  - Another topic, Section 9 (IANA Considerations) reads:
>> >
>> >     Further, this document registers a Early authentication usage label
>> >     from the "USRK Key Labels" name space with a value:
>> >
>> >        EAP Early-Authentication RootKey <at> ietf.org
>> >
>> >
>> >  I am missing the sentence to name the master registry where the USRK Key
(Continue reading)

Permalink | Reply | 3 comments |
headers
Miguel A. Garcia | 3 Feb 08:57
Picon
Favicon

Re: Gen-ART review of draft-ietf-hokey-erp-aak-07

Hi Qin Wu:

As far as I remember, there is a policy in force that does not allow URLs 
in RFCs, in particular in the IANA section. I believe that the motivation 
is that URLs can change with time.

The proposal is (something around these lines):

     Further, this document instructs IANA to add a new lable in the User 
Specific Root Keys (USRK) Key Labels of the Extended Master Session Key 
(EMSK) Parameters registry, as follows:

         EAP Early-Authentication Root Key <at> ietf.org

/Miguel

On 03/02/2012 8:43, Qin Wu wrote:
> Hi, Miguel:
> I think you are looking for this registry.
> http://www.iana.org/assignments/emsk-parameters/emsk-parameters.xml
> To make clear, the proposed change is replace the OLD Text
> "
> Further, this document registers a Early authentication usage label
>     from the "USRK Key Labels" name space with a value:
>
>        EAP Early-Authentication Root Key <at> ietf.org
> "
> With the NEW Text:
> "
> Further, this document registers a Early authentication usage label
(Continue reading)

Permalink | Reply | 1 comment |
headers
Alexey Melnikov | 3 Feb 14:14
Favicon

Re: [OAUTH-WG] Gen-ART review of draft-ietf-oauth-v2-bearer-15.txt

On 31/01/2012 10:33, Alexey Melnikov wrote:
> On 30/01/2012 05:20, Mike Jones wrote:
  [...]
>> About your third minor issue on RFC 6125 versus RFC 2818, you'll find 
>> that, per the history entries, a previous reference to RFC 2818 was 
>> changed to RFC 6125 in draft 14 at the request of Security Area 
>> Director Stephen Farrell.
I've quickly chatted with Stephen and he said that he only asked the 
question and didn't necessarily instructed the WG to do the change from 
RFC 2818 to RFC 6125. Keeping this in mind...
>> If you'd like to see this reference reintroduced, I'd request that 
>> you work with Stephen on specific alternative proposed wording that 
>> is acceptable to both of you.
>  Ok, I can work with Stephen and Peter Saint-Andre (RFC 6125 
> co-author) on some text.

So, here are the proposed changes:

4.2.  Threat Mitigation

      To protect against token disclosure, confidentiality protection MUST
      be applied using TLS [RFC5246] with a ciphersuite that provides
      confidentiality and integrity protection.  This requires that the
      communication interaction between the client and the authorization
      server, as well as the interaction between the client and the
      resource server, utilize confidentiality and integrity protection.
      Since TLS is mandatory to implement and to use with this
      specification, it is the preferred approach for preventing token
      disclosure via the communication channel.  For those cases where the
      client is prevented from observing the contents of the token, token
(Continue reading)

Permalink | Reply | 1 comment |
headers
Stephen Farrell | 3 Feb 14:17
Picon
Picon

Re: [OAUTH-WG] Gen-ART review of draft-ietf-oauth-v2-bearer-15.txt


That looks fine to me fwiw,
Thanks,
S.

On 02/03/2012 01:14 PM, Alexey Melnikov wrote:
> On 31/01/2012 10:33, Alexey Melnikov wrote:
>> On 30/01/2012 05:20, Mike Jones wrote:
> [...]
>>> About your third minor issue on RFC 6125 versus RFC 2818, you'll find
>>> that, per the history entries, a previous reference to RFC 2818 was
>>> changed to RFC 6125 in draft 14 at the request of Security Area
>>> Director Stephen Farrell.
> I've quickly chatted with Stephen and he said that he only asked the
> question and didn't necessarily instructed the WG to do the change from
> RFC 2818 to RFC 6125. Keeping this in mind...
>>> If you'd like to see this reference reintroduced, I'd request that
>>> you work with Stephen on specific alternative proposed wording that
>>> is acceptable to both of you.
>> Ok, I can work with Stephen and Peter Saint-Andre (RFC 6125 co-author)
>> on some text.
>
> So, here are the proposed changes:
>
> 4.2. Threat Mitigation
>
> To protect against token disclosure, confidentiality protection MUST
> be applied using TLS [RFC5246] with a ciphersuite that provides
> confidentiality and integrity protection. This requires that the
> communication interaction between the client and the authorization
(Continue reading)

Permalink | Reply | 0 comments |
headers
Qin Wu | 3 Feb 05:53
Favicon

Re: Gen-art review of draft-ietf-dime-pmip6-lr-07

Hi,Elwyn:
Thank for your valuable review. please see our replies below.
----- Original Message ----- 
From: "Elwyn Davies" <davieseb <at> scss.tcd.ie>
To: "General Area Review Team" <gen-art <at> ietf.org>
Cc: <draft-ietf-dime-pmip6-lr.all <at> tools.ietf.org>
Sent: Thursday, February 02, 2012 9:06 PM
Subject: Gen-art review of draft-ietf-dime-pmip6-lr-07

>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-dime-pmip6-lr-07.txt
> Reviewer: Elwyn Davies
> Review Date: 2 February 2012
> IETF LC End Date: 24 January 2012
> IESG Telechat date: 16 February 2012
> 
> Summary:
> I have a couple of queries/minor issues regarding checking whether LMA1
> and LMA2 are the same node and some hand waving over the idea of
> 'localized routing setup/signaliing'.  There are also a few minor nits.
> Otherwise this is ready for the IESG.
> 
> [This document missed the normal gen-art last call allocation
> notification mechanism for some reason - so I didn't realize it was on
(Continue reading)

Permalink | Reply | 8 comments |

Gmane