Subject: [Dime] [dime] Re: Spencer Dawkins' No Objection on draft-ietf-dime-4over6-provisioning-04: (with COMMENT)

From: Qiong <[email-masked]>
Date: Thu, 6 Aug 2015 15:13:09 +0800

Dear Spencer,

This is Qiong Sun. My email address ([email-masked]) is correct, but
it seems blocked the emails from
[email-masked] and  I cannot send the email
neither. I will contact the IT in my office ASAP.

Thanks!

Best wishes
Qiong

From: Spencer Dawkins at IETF [mailto:[email-masked]]
Sent: Tuesday, August 04, 2015 11:28 PM
To: The IESG
Cc: [email-masked]; [email-masked];
[email-masked]; [email-masked];
[email-masked];
[email-masked]
Subject: Re: Spencer Dawkins' No Objection on
draft-ietf-dime-4over6-provisioning-04: (with COMMENT)

Just curious. Does anyone have an updated address for Sun Qiong?

I'm getting

<[email-masked]> (expanded from
    <[email-masked]>): host
    mail.ctbri.com.cn[219.142.69.47] said: 554 5.7.1 Error: invalid sender
by
    SPF from 4.31.198.44 (in reply to RCPT TO command)

Final-Recipient: rfc822; [email-masked]
Original-Recipient: rfc822;
[email-masked]
Action: failed
Status: 5.7.1
Remote-MTA: dns; mail.ctbri.com.cn
Diagnostic-Code: smtp; 554 5.7.1 Error: invalid sender by SPF from
4.31.198.44

Thanks!

Spencer

On Tue, Aug 4, 2015 at 10:23 AM, Spencer Dawkins <
[email-masked]> wrote:
Spencer Dawkins has entered the following ballot position for
draft-ietf-dime-4over6-provisioning-04: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-dime-4over6-provisioning/

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

A nit - this text

   [RFC6519] sets a precedent for representation of the IPv6 address of
   a border router as an FQDN.  This can be dereferenced to one or more
   IP addresses by the provisioning system before being passed to the
   customer equipment, or left as an FQDN as it as in [RFC6334].
                                          ^^^^^^^^^^^

seems garbled.

In this text

3.4.1.  Delegated-IPv6-Prefix As the IPv6 Binding Prefix

   The Delegated-IPv6-Prefix AVP (AVP code 123) is of type Octetstring,
   and is defined in [RFC4818].  Within the Tunnel-Source-Pref-Or-Addr
   AVP, it conveys the IPv6 Binding Prefix assigned to the CE.  Valid
   values in the Prefix-Length field are from 0 to 128 (full address),
   although a more restricted range is obviously more reasonable.
                                       ^^^^^^^^^^^^^^^^^^^^^^^^^
I wonder if "obviously more reasonable" is the right thing to say. Is
this saying something like "more scalable" (compared to bunches of
128-bit IP binding prefixes)? Or am I misunderstanding the point?

-- 
==============================================
Qiong Sun
China Telecom Beijing Research Institude

Open source code:
lightweight 4over6: *http://sourceforge.net/projects/laft6/
<http://sourceforge.net/projects/laft6/>*
PCP-natcoord:* http://sourceforge.net/projects/pcpportsetdemo/
<http://sourceforge.net/projects/pcpportsetdemo/> *
===============================================