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

[<[e-mail]>]

Hi Spencer,

Thank you for the review. 

Please see inline.

Cheers,
Med

> -----Message d'origine-----
> De : Spencer Dawkins [mailto:[e-mail]]
> Envoyé : mardi 4 août 2015 17:24
> À : The IESG
> Cc : MORAND Lionel IMT/OLN; [e-mail]; draft-ietf-dime-4over6-
> [e-mail]; [e-mail];
> [e-mail]; [e-mail]
> Objet : Spencer Dawkins' No Objection on draft-ietf-dime-4over6-
> provisioning-04: (with COMMENT)
> 
> 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].
>                                           ^^^^^^^^^^^
> 
[Med] Fixed.

> 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?
> 
[Med] "more reasonable" is used because hosts are usually provisioned with prefixes such as /48, /56 or /64 (which are "restricted ranges"). 

We can delete "although a more restricted range is obviously more reasonable" if this is confusing.