Christer Holmberg | 1 Jan 11:19 2011
Picon

RE: Gen-ART LC review of draft-ietf-sipcore-keep-10

Hi Roni,

>Summary: This draft is almost ready for publication as a Standard track RFC.
>
>Major issues:
>
>
>Minor issues:
>
>1.  In the document you mention that the keep alive can be negotiated in each direction. I understand the
dialog case, is this true 
>for the case of registration, if yes how is it done from the registrar. If not true maybe add some text in 4.2.2.

Good point. It is NOT true for the case of registration, when sending of keep-alives can only be negotiated
from the registering party to the registrar.

I suggest adding the following text to the end of section 4.2.2:

"NOTE: Sending of keep-alives associated with a registration can only be negotiated in the direction from
the registering SIP entity towards the registrar."

-----

>Nits/editorial comments:
>
>1.  In section 4.1 in the first note “If a SIP entity has indicated willingness to receive keep-alives
from an adjacent SIP entity, 
>sending of keep-alives towards the same SIP entity needs to be separately negotiated”. 
>
>Who is the same SIP entity mentioned in the end of the sentence. I assume you meant “towards the adjacent
(Continue reading)

Brian E Carpenter | 1 Jan 21:00 2011
Picon

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
Brian E Carpenter | 1 Jan 21:09 2011
Picon

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

Roni Even | 1 Jan 23:30 2011
Picon

RE: Gen-ART LC review of draft-ietf-sipcore-keep-10

Hi Christer,
I am OK with all your responses
regards
Roni

> -----Original Message-----
> From: Christer Holmberg [mailto:christer.holmberg <at> ericsson.com]
> Sent: Saturday, January 01, 2011 12:20 PM
> To: Roni Even; gen-art <at> ietf.org; draft-ietf-sipcore-
> keep.all <at> tools.ietf.org
> Cc: 'IETF-Discussion list'
> Subject: RE: Gen-ART LC review of draft-ietf-sipcore-keep-10
> 
> Hi Roni,
> 
> >Summary: This draft is almost ready for publication as a Standard
> track RFC.
> >
> >Major issues:
> >
> >
> >Minor issues:
> >
> >1.  In the document you mention that the keep alive can be negotiated
> in each direction. I understand the dialog case, is this true
> >for the case of registration, if yes how is it done from the
> registrar. If not true maybe add some text in 4.2.2.
> 
> Good point. It is NOT true for the case of registration, when sending
> of keep-alives can only be negotiated from the registering party to the
(Continue reading)

Mary Barnes | 2 Jan 19:24 2011
Picon

Assignments for Jan 6, 2011 Telechat

Hi all,

Here's the link to the summary of assignments for the Jan 6th, 2011 telechat:

With the updated spreadsheets:

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:

Mary.

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

I am the assigned Gen-ART reviewer for this draft. For background on
Gen-ART, please see the FAQ at

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

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
Suresh Krishnan | 3 Jan 03:29 2011
Picon

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.
> 
> 
> 
> 
Suresh Krishnan | 3 Jan 03:32 2011
Picon

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
> >
> 
> 
Suresh Krishnan | 3 Jan 03:37 2011
Picon

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
Suresh Krishnan | 3 Jan 04:26 2011
Picon

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
Suresh Krishnan | 3 Jan 04:47 2011
Picon

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

Gmane