Subject: [Gen-art] A *new* batch of IETF LC reviews - 2014-10-08

From: "A. Jean Mahoney" <[email-masked]>
Date: Wed, 08 Oct 2014 16:11:56 -0500

Hi all,

The following reviewers have assignments:

Reviewer          LC end       Draft
---------------------------------------------------------------------

Russ Housley      2014-10-21   draft-ietf-tram-alpn-06

Suresh Krishnan   2014-10-17   draft-ietf-ospf-security-extension-manual-keying-08

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

And 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

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:
IETF LC End Date:
IESG Telechat date: (if known)

Summary:

Major issues:

Minor issues:

Nits/editorial comments:

---

From: "A. Jean Mahoney" <[email-masked]>
Date: Wed, 08 Oct 2014 16:39:09 -0500

And one more:

Reviewer          LC date       Draft

Tom Taylor        2014-10-31   draft-young-entity-category-02 *

* Early review

Thanks,

Jean

On 10/8/14, 4:11 PM, A. Jean Mahoney wrote:
> Suresh Krishnan   2014-10-17 
> draft-ietf-ospf-security-extension-manual-keying-08
>
>
> _______________________________________________
> Gen-art mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/gen-art

---

From: "Joel M. Halpern" <[email-masked]>
Date: Wed, 08 Oct 2014 19:20:17 -0400

Document: draft-ietf-mpls-lsp-ping-relay-reply-04
     Relayed Echo Reply mechanism for LSP Ping
Reviewer: Joel M. Halpern
Review Date: 8-October-2014
IETF LC End Date: 13-October-2014
IESG Telechat date: (if known)

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

Major issues:
     There is either a major technical flaw in this document, or there 
is a need for significantly better explanation.  The following is what I 
was able to understand from reading the document.
     The procedure in the document calls for a responding or relaying 
LSR to search the response addresses from the top to the bottom (top 
being the originator of the request, bottom being visible originators). 
  The responder then sends the reply to the first usable address it can 
find in the stack.  Usable is variously described as "public routable" 
and as "routable" (in sections 4.2), the converse is described as 
"unroutable" in section 4.3, while section 4.4 uses "routable".
If it means "routable", then this assumes that the private addresses 
used by one AS will not happen to also be used in another AS (which 
would make them routable in that domain, directing the reply to 
completely the wrong place.
If it means "publicly routable", this would seem to fail since routers 
do not know whether routable addresses are public, private, or simply 
not martian.

Minor issues:
     The procedures assume that border routers will know the correct 
address to put in the reply stack.  It is not bovious that even if the 
router has a public address, it will get put on.  The requirement stated 
here is that the address put on be the same one used to originate the 
reply.  Which would seem likely to be na internal address in many cases.

     The procedure for setting k=0 allowing entries to be removed from 
the stack seems fragile.  It relies on routers being able to determine 
that their address will not be needed for relay by the next hop.

Nits/editorial comments:
    Some of the procedure for originating a reply is described in 
section 4.2 on Receiving a request, rather than in seciton 4.3 on 
originating the reply.  (Information such as the address to put on the 
stack, where it goes on the stack, and the handling of the reply packet 
being too large all belong in 4.3.)