Re: [Gen-art] Gen-ART Telechat Review of draft-ietf-pcn-encoding-comparison-08

[Bob Briscoe <[e-mail]>]

Pete,

Thanks. You're right re S.3.3.3.4.

Suggest delete/ (like the limited functionality option in Section 3.3.3.1)/

I also suggest the end of 3.3.3. needs to mention RFC6040, rather 
than waiting until 3.3.3.4, which otherwise looks like an afterthought.

OLD 3.3.3:
=====================================================================
                          Two different modes are defined in [RFC3168]
    for IP-in-IP tunnels and a third one in [RFC4301] for IP-in-IPsec
    tunnels.
=====================================================================
NEW 3.3.3:
=====================================================================
                          Two different modes are defined in [RFC3168]
    for IP-in-IP tunnels and a third one in [RFC4301] for IP-in-IPsec
    tunnels. [RFC6040] updates both these RFCs to rationalise them into
    one consistent approach.
=====================================================================


Agree that all identified nits need correcting.

Thanks again for your time on this.



Bob

At 04:33 29/02/2012, Pete McCann wrote:
>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-pcn-encoding-comparison-08
>Reviewer: Peter McCann
>Review Date: 2012-02-28
>IETF LC End Date:
>IESG Telechat date: 2012-03-01
>
>Summary: Ready
>
>Major issues: None
>
>Minor issues:
>
>Section 3.3.3.4:
>    With the normal mode, the ECN field of the inner header is copied to
>    the ECN field of the outer header on encapsulation (like the limited
>    functionality option in Section 3.3.3.1).
>The limited functionality option says to set the outer header to not-ECT.
>This seems to contradict the above statement.
>
>Nits/editorial comments:
>
>Section 3.3.3.3:
>    full-
>    functionality option in Section 3.3.2.2.
>I think you meant "Section 3.3.3.2".  One other place in this
>paragraph needs this correction.
>
>Section 4.2:
>    The problem with 3-in-1 encoding is that the 10-codepoint does not
>    survive decapsulation with the tunneling options in Section 3.3.2.1 -
>    3.3.2.3.
>Again, you meant 3.3.3.1 - 3.3.3.3

________________________________________________________________
Bob Briscoe,                                BT Innovate & Design