RE: Last Call: <draft-ietf-behave-lsn-requirements-07.txt> (Common requirements for Carrier Grade NATs (CGNs)) to Best Current Practice

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



I have a comment about this document related to some discussions that I've had with a number of ADs and WG chairs around the formation and charter of Sunset4 to determine what is and is not in scope for that WG.

For a while both BEHAVE and Sunset4 had this document in their milestones, which clearly won't work. Therefore the distinction made between work to be done in BEHAVE and SUNSET4 was that BEHAVE was to focus more generically on the concept of NAT and the things necessary to make all flavors of it work, such that BEHAVE outputs would equally apply to NAT444, NAT64, DSLite, etc. By contrast, Sunset4 was supposed to focus more narrowly on IPv4-only items. The BEHAVE chairs were represented in these discussions, and they believed that this document was in keeping with this distinction.
In the document's introduction, for example, that generic nature is implied:
  "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."

However, this document states in section 2:
  "Note also that the CGN described in this document is IPv4-only.
   IPv6 address translation is not considered."
I see that this is a new change to the -07 version, so I hate to rehash the discussion, but I think that this statement should be clearer.
In reading the document, I don't believe that the intent was to limit it to being a discussion of NAT44[4], but that could be the way that this statement is interpreted. The distinction I might make to clarify is that since the document is talking about behaviors that are necessary to make IPv4 address-sharing work, it's specific to the IPv4 side of what could well be a dual-stack NAT, but it's not limited to simply NAT44[4].

I'm not advocating pulling this document back so that it can go to the "right" working group, because I don't think that'll actually add any value to the document and I'm not a fan of process for process's sake. My concern is really more about content and naming- if it is truly a IPv4-only NAT (NAT44 or NAT444) requirements doc rather than a more generic CGN requirements doc, it should be named to reflect that. If it's meant to be a generic LSN requirements doc, the authors should make the appropriate changes to keep it generic.

Thanks,

Wes George, at least partially wearing my Sunset4 chair hat



> -----Original Message-----
> From: ietf-announce-bounces@xxxxxxxx [mailto:ietf-announce-
> bounces@xxxxxxxx] On Behalf Of The IESG
> Sent: Tuesday, June 26, 2012 12:59 PM
> To: IETF-Announce
> Cc: behave@xxxxxxxx
> Subject: Last Call: <draft-ietf-behave-lsn-requirements-07.txt> (Common
> requirements for Carrier Grade NATs (CGNs)) to Best Current Practice
>
>
> The IESG has received a request from the Behavior Engineering for
> Hindrance Avoidance WG (behave) to consider the following document:
> - 'Common requirements for Carrier Grade NATs (CGNs)'
>   <draft-ietf-behave-lsn-requirements-07.txt> as Best Current Practice
>
> The IESG plans to make a decision in the next few weeks, and solicits
> final comments on this action. Please send substantive comments to the
> ietf@xxxxxxxx mailing lists by 2012-07-10. Exceptionally, comments may
> be sent to iesg@xxxxxxxx instead. In either case, please retain the
> beginning of the Subject line to allow automated sorting.
>
> Abstract
>
>
>    This document defines common requirements for Carrier-Grade NAT
>    (CGN).  It updates RFC 4787.
>
>
>
>
> The file can be obtained via
> http://datatracker.ietf.org/doc/draft-ietf-behave-lsn-requirements/
>
> IESG discussion can be tracked via
> http://datatracker.ietf.org/doc/draft-ietf-behave-lsn-
> requirements/ballot/
>
>
> The following IPR Declarations may be related to this I-D:
>
>    http://datatracker.ietf.org/ipr/1648/
>
>


This E-mail and any of its attachments may contain Time Warner Cable proprietary information, which is privileged, confidential, or subject to copyright belonging to Time Warner Cable. This E-mail is intended solely for the use of the individual or entity to which it is addressed. If you are not the intended recipient of this E-mail, you are hereby notified that any dissemination, distribution, copying, or action taken in relation to the contents of and attachments to this E-mail is strictly prohibited and may be unlawful. If you have received this E-mail in error, please notify the sender immediately and permanently delete the original and any copy of this E-mail and any printout.



[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]