RE: Review of 'draft-xu-v6ops-hybrid-framework-00.txt'

["Templin, Fred L" <[e-mail]>]

Hi Sheng,

> -----Original Message-----
> From: Sheng Jiang [mailto:[e-mail]]
> Sent: Monday, September 07, 2009 10:14 AM
> To: Templin, Fred L; 'v6ops'
> Cc: [e-mail]; 'Brian E Carpenter'
> Subject: RE: Review of 'draft-xu-v6ops-hybrid-framework-00.txt'
> 
> Hi, Templin,
> 
> Thanks so much for your reviewing and comments.
> 
> All of your comments are accepted and will be reflected in the next
version,
> except for the below one. Can I ask you a question here: overall, do
you
> think this draft is suitable for v6ops charter and mature enough to be
> adopted as wg file?
> 
> > 8) Section 3, second paragraph beginning: "In order to
> > find NATs and traverse them,", this text seems to imply
> > that *all* applications need to be made NAT-aware when
> > in fact many/most applications are oblivious to NATs.
> > Is there a certain class of applications this text is
> > meaning to refer to? If so, the assumptions must be
> > stated.
> 
> I guess, this refer is to these applications that want to traverse
NATs. If
> you have any specific text to suggest, we may adopt it in the next
version.

I guess when I think of NAT discovery and traversal, I
think of NAT-specific end system services like STUN, TURN,
ICE, TEREDO, etc. and not about "ordinary" IPv4 applications
like ftp, web browsing, etc. Here is a proposed rewrite that
I think could accommodate the concern:

  "In order to find NATs and traverse them, end system services
   have to understand network protocols deeply, invoke or interact
   with network protocols directly and analyse network behaviours
   by themselves, since the protocol stack on the end system is
   not aware of NATs.

Fred
[e-mail]

> Many thanks and best regards,
> 
> Sheng
> 
> > -----Original Message-----
> > From: [e-mail] [mailto:[e-mail]] On
Behalf
> > Of Templin, Fred L
> > Sent: Thursday, September 03, 2009 5:21 AM
> > To: v6ops
> > Cc: [e-mail]; JiangSheng 66104; Brian E Carpenter
> > Subject: Review of 'draft-xu-v6ops-hybrid-framework-00.txt'
> >
> > Below is my review of 'draft-xu-v6ops-hybrid-framework-00.txt':
> >
> > Fred
> > [e-mail]
> >
> > ---
> >
> > 1) Abstract, the phrase "as many as possible" seems at
> > odds with trusting the ISP to make informed choices.
> > Suggest changing this to: "ISP networks may need to
> > support multiple IPv6 connectivity solutions".
> >
> > 2) Section 1, paragraph 3, the phrase: "including the support
> > of configured IPv6-over-IPv4 tunnels" should be shortened to
> > "including the support of IPv6-over-IPv4 tunnels".
> >
> > 3) Section 1, paragraph 3, the phrase: "cannot be sufficient
> > once IPv4 addresses have run out, because it" is not correct,
> > because dual stack can still be used in environments that
> > use IPv4 privacy addresses, which can exist even after the
> > global IPv4 address run-out. Suggest shortening sentence to:
> >
> >   "However, the dual stack approach does not allow IPv6-only
> >    hosts to communicate with IPv4-only hosts."
> >
> > which is true under any circumstances.
> >
> > 4) Section 1, paragraph beginning with "Each technique...",
> > add VET to the "For example" list, i.e., as:
> >
> >   "For example, VET (Virtual Enterprise Traversal [VET]),
> >    6RD (IPv6 Rapid Deployment [6RD]), Port Range ..."
> >
> > 5) Section 1, paragraph beginning with "Up to now",
> > change: "ISP networks need to support as many IPv6
> > connectivity solutions as is operationally reasonable"
> > to" "ISP networks may need to support multiple IPv6
> > connectivity solutions".
> >
> > 6) Section 2, third paragraph, the trailing sentence: "Note
> > that IPv6 autoconfiguration is not powerful enough for this
> > purpose." does not seem to add any value and may instead
> > serve only to confuse. Can this sentence be dropped?
> >
> > 7) Section 2, the paragraph beginning: "The hybrid ISP
> > framework", change first sentence to: "The hybrid ISP
> > framework may need to support multiple IPv6 connectivity
> > solutions."
> >
> > 8) Section 3, second paragraph beginning: "In order to
> > find NATs and traverse them,", this text seems to imply
> > that *all* applications need to be made NAT-aware when
> > in fact many/most applications are oblivious to NATs.
> > Is there a certain class of applications this text is
> > meaning to refer to? If so, the assumptions must be
> > stated.
> >
> > 9) Section 4.2 should also cite IPv6 Prefix Options for
> > DHCPv6 [RFC3633].
> >
> > 10) Section 4.3, DNS SRV is not the only method used for
> > service resolution. Remove the phrase: "using DNS SRV
> > [2782]".