Gen-ART telechat review of draft-ietf-pim-group-rp-mapping-08.txt

Please see attached review.

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-pim-group-rp-mapping-08.txt
Reviewer: Brian Carpenter
Review Date: 2011-01-02
IETF LC End Date: 2010-12-23
IESG Telechat date: 2011-01-06

Summary: Ready
--------

Thanks for fixing my Last Call comments.

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

Gen-ART telechat review of draft-loreto-http-bidirectional-05.txt

Please see attached review.

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-loreto-http-bidirectional-05.txt
Reviewer: Brian Carpenter
Review Date: 2011-01-02
IETF LC End Date: 2010-12-21
IESG Telechat date: 2011-01-06

Summary: Almost ready
--------

After some discussion of my LC comment, the authors agreed to:

> add a sentence stating that the
> proposed techniques stretch the original semantic of HTTP and that the
> HTTP protocol was not designed for this use... 

Could be done by RFC Editor note.

_______________________________________________
Gen-art mailing list

Assignments for Jan 6, 2011 Telechat

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

Re: Gen-ART LC review of draft-ietf-v6ops-tunnel-security-concerns-04.txt

Hi Brian,
  I see your point about the placement of Section 7. Would moving Section 7 much earlier in the document
address your concern? If so, I can move it to Section 1.1 or (a new) Section 2. Do you think any more text is needed?

Thanks
Suresh

> -----Original Message-----
> From: gen-art-bounces <at> ietf.org 
> [mailto:gen-art-bounces <at> ietf.org] On Behalf Of Brian E Carpenter
> Sent: Monday, December 27, 2010 8:19 PM
> To: 
> draft-ietf-v6ops-tunnel-security-concerns.all <at> tools.ietf.org; 
> General Area Review Team
> Subject: [Gen-art] Gen-ART LC review of 
> draft-ietf-v6ops-tunnel-security-concerns-04.txt
> 
> Please see attached review.
> 
> 
> 
> 

Re: Gen-ART Last Call review of draft-arkko-ipv6-transition-guidelines-12.txt

Hi Jari,
  I looked over the new version and it addresses my comments. Thanks for the quick turnaround.

Cheers
Suresh

> -----Original Message-----
> From: Jari Arkko [mailto:jari.arkko <at> piuha.net] 
> Sent: Monday, December 27, 2010 4:59 PM
> To: Suresh Krishnan
> Cc: General Area Review Team; 
> draft-arkko-ipv6-transition-guidelines.all <at> tools.ietf.org
> Subject: Re: Gen-ART Last Call review of 
> draft-arkko-ipv6-transition-guidelines-12.txt
> 
> Thank you Suresh for these comments. I have addressed all of 
> them in -14.
> 
> Jari
> 
> Suresh Krishnan kirjoitti:
> > I am the assigned Gen-ART reviewer for 
> > draft-arkko-ipv6-transition-guidelines-12.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 well written and is ready for 
> publication as an 
> > Informational RFC but has some minor issues that need to be fixed.
> >
> > Minor
> > =====
> >
> > * Section 2
> >
> > NAT-PT was defined in RFC2766 and not in RFC4966 (which 
> deprecated it).
> >
> > Suggest replacing
> >
> > NAT-PT:  refers to a specific, old design of a Network Address 
> > Translator - Protocol Translator defined in [RFC4966].
> >
> > with
> >
> > NAT-PT:  refers to a specific, old design of a Network Address 
> > Translator - Protocol Translator defined in [RFC2766] and 
> deprecated 
> > due to the reasons stated in [RFC4966].
> >
> >
> > * Section 3.1
> >
> > "  For instance, a service provider network might stop 
> providing IPv4
> >    service within its own network, while still allowing its IPv6
> >    customers to access the rest of the IPv4 Internet 
> through overlay or
> >    proxy services."
> >
> > IPv6-IPv4 translation could also be used as a sunsetting mechanism. 
> > Could you include this as an option. e.g.
> >
> > "  For instance, a service provider network might stop 
> providing IPv4
> >    service within its own network, while still allowing its IPv6
> >    customers to access the rest of the IPv4 Internet 
> through overlay,
> >    proxy, or translation services."
> >
> > Thanks
> > Suresh
> >
> 
> 

Gen-ART Last Call review of draft-arkko-ipv6-transition-guidelines-14.txt

I am the assigned Gen-ART reviewer for
draft-arkko-ipv6-transition-guidelines-14.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 an Informational RFC.

Thanks
Suresh

Gen-ART Telechat review of draft-ietf-avt-rtp-cnames-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-avt-rtp-cnames-03.txt
Reviewer: Suresh Krishnan
Review Date: 2011/01/02
IESG Telechat date: 2011/01/06

Summary: This draft has addressed my comments from the previous Last 
Call review but has a new issue that needs to be fixed before 
publication as a Proposed Standard.

* Section 5 Step 2

This step describes the use of an EUI-64 identifier and how to generate 
one if it does not exists. The procedure for the creation of the EUI-64 
from a 48 bit MAC address is incorrect.

RFC4291 describes how to create a **modified EUI-64** identifier (and 
not a EUI-64 identifier) from a MAC address.

A MAC address of xx:78:90:12:34:56 will be transformed to a modified 
EUI-64 of

yy7890FFFE123456

where yy is the value of xx with the u/l bit (bit 6) flipped.

The IEEE reference for creation of an EUI-64 from a 48 bit MAC address

http://standards.ieee.org/develop/regauth/tut/eui64.pdf

would result in an EUI-64 of

xx7890FFFF123456 for the same MAC address.

I understand that there will be no interoperability issues due to this 
(since the cname is opaque) but there may be issues with testing 
compliance (since the expected hash values will be way off).

I recommend either using the term "modified EUI-64" instead of EUI-64 or 
changing the reference from RFC4291 to the IEEE document in order to fix 
this inconsistency.

Thanks
Suresh

Gen-ART Telechat review of draft-ietf-pkix-ocspagility-09.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-pkix-ocspagility-09.txt
Reviewer: Suresh Krishnan
Review Date: 2011/01/02
IESG Telechat date: 2011/01/06

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

Thanks
Suresh

Gen-ART Telechat review of draft-ietf-roll-trickle-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 wait for direction from your document shepherd
or AD before posting a new version of the draft.

Document: draft-ietf-roll-trickle-06.txt
Reviewer: Suresh Krishnan
Review Date: 2011/01/02
IESG Telechat date: 2011/01/06

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

Thanks
Suresh

Re: Gen-ART LC review of draft-ietf-v6ops-tunnel-security-concerns-04.txt

Suresh,

Let's wait and see if the IESG requests any changes. Maybe even one
sentence in the Introduction would be enough to alert the reader to the
recommendations?

    Brian

On 2011-01-03 15:29, Suresh Krishnan wrote:
> Hi Brian,
>   I see your point about the placement of Section 7. Would moving Section 7 much earlier in the document
address your concern? If so, I can move it to Section 1.1 or (a new) Section 2. Do you think any more text is needed?
> 
> Thanks
> Suresh
> 
> 
>> -----Original Message-----
>> From: gen-art-bounces <at> ietf.org 
>> [mailto:gen-art-bounces <at> ietf.org] On Behalf Of Brian E Carpenter
>> Sent: Monday, December 27, 2010 8:19 PM
>> To: 
>> draft-ietf-v6ops-tunnel-security-concerns.all <at> tools.ietf.org; 
>> General Area Review Team
>> Subject: [Gen-art] Gen-ART LC review of 
>> draft-ietf-v6ops-tunnel-security-concerns-04.txt
>>
>> Please see attached review.
>>
>>
>>
>>