Re: [BEHAVE] AD review of LSN requirements draft

["Dan Wing" <[e-mail]>]

> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]] On
> Behalf Of Wesley Eddy
> Sent: Wednesday, May 30, 2012 9:19 PM
> To: [e-mail]
> Cc: [e-mail]
> Subject: [BEHAVE] AD review of LSN requirements draft
> 
> Hi, I've completed an AD review of the LSN requirements draft.
> 
> I think it's generally in pretty good shape, but do have some
> comments that we should at least talk about before going forward.
> This could require a small update.  I also understand from the
> mailing list that Simon has a proposed reversal of one of the
> previous changes, and I think he's totally correct.  So, we
> should get a revision anyways before moving on.
> 
> Here are my comments:
> 
> (1) it strongly seems like RFC 6264 should be mentioned here;
> it would probably work in the 2nd paragraph of the Introduction
> about providing IPv6 services alongside IPv4 CGN
> 
> (2) it seems like it should be really clear in section 1 that
> this document isn't considering multi-subscriber IPv6 NPT or
> dual layers of IPv6 NPT as being a CGN, only multi-subscriber
> IPv4 NAT and dual layers of IPv4 NAT
> 
> (3) Note that the sub-requirements for individual NAT
> behavior RFCs are labelled "REQ-1", "REQ-2", etc.
> duplicatively with the higher-level REQ-1, REQ-2, etc.
> 
> (4) Several of the requirements have "SHOULD" in them,
> which makes them more of a recommendation than an
> actual requirement (those are MUSTs!); if we want to
> retain "SHOULD"s, then we probably need to suggest
> why they aren't MUSTs by giving some cogent example
> of a case where it would be acceptable not to implement
> the feature.  (this applies to the SHOULD NOTs as well)
> 
> (5) Should there be a requirement to support use of
> the prefix allocated via RFC 6598?
> 
> (6) I think it would be good to have an advisory
> reference to the issues in:
> http://tools.ietf.org/html/draft-donley-nat444-impacts-03
> and whether or not following the recommendations in this
> document helps to avoid such issues.  The RFC 6269
> reference already in the introduction is okay, but it
> probably glosses over this topic too quickly.

The test results of draft-donley-nat444-impacts received comments
by myself and Reinaldo Penno in 2010,
  http://www.ietf.org/mail-archive/web/behave/current/msg09027.html
  http://www.ietf.org/mail-archive/web/behave/current/msg09030.html
and the authors have been unable to provide sufficient detail for
others to duplicate the test results.  

> (7) I suspect that we should be more clear in the abstract
> and introduction that this is not an IETF endorsement of
> CGN or a real specification for CGN, but rather just a
> minimal set of requirements that we believe need to be
> followed for implementing CGNs on the Internet; CGNs are
> still not something we have consensus on being desirable
> for the Internet.

-d