Re: [BEHAVE] AD review of LSN requirements draft

[Simon Perreault <[e-mail]>]

On 2012-05-31 00:19, Wesley Eddy wrote:
> 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

Added:
One approach to CGN deployment is described in <xref target="RFC6264"/>.

> (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

Added:
Note that the CGN mechanism described in this document only applies to 
IPv4. Any IPv6 address translation is out of scope.

Also tweaked the definition of CGN in the terminology section.

> (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.

Already mentioned to me privately and fixed in my copy.

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

My intent as editor has always been to include justification for any SHOULD.

e.g.
       Sending an ICMP error may be rate-limited for security reasons,
       which is why requirement B is a SHOULD, not a MUST.

Proposal: I'll make a list of justification-less SHOULDs and submit it 
to the WG so that we can either turn them into MUSTs or add justification.

> (5) Should there be a requirement to support use of
> the prefix allocated via RFC 6598?

I can't see how any networking equipment could not support it.

> (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.

In addition to Dan's response, the draft-donley does not evaluate CGNs 
that have a PCP server, which our draft requires. I think the inclusion 
of PCP would affect the results significantly.

> (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.

I added this:
"It is not an IETF endorsement of CGN or a real specification for CGN, 
but rather just a minimal set of requirements that will increase the 
likelihood of applications working across CGNs."

But I believe it would be more appropriate to put such text in an IESG Note.

Simon
-- 
DTN made easy, lean, and smart --> http://postellation.viagenie.ca
NAT64/DNS64 open-source        --> http://ecdysis.viagenie.ca
STUN/TURN server               --> http://numb.viagenie.ca