Subject: [v6ops] Call for Adoption: draft-templin-v6ops-pdhost

From: Ron Bonica <[email-masked]>
Date: Thu, 26 Jul 2018 17:25:08 +0000

Folks,

This draft initiates a two week call for adoption on draft-templin-v6ops-pdhost. Please respond by August 9, 2018.

                                                                     Ron

---

From: Lorenzo Colitti <[email-masked]>
Date: Fri, 27 Jul 2018 17:46:06 +0900

I have read the draft and support adoption. The document is a general
discussion of how hosts can benefit from multiple addresses that is
agnostic to the way the prefix is delivered, and it fits well with the
spirit of RFC 7934.

I note that Section 8 seems to specify host behaviour, which is typically
not in scope for v6ops. To my mind that doesn't preclude adoption since it
can be reworded in a way that doesn't specify host behaviour but only
specifies the consequences of potential changes to host behaviour that
specified by other working groups such as 6man.

Section 10 should mention the de-facto prefix delegation mechanism used by
all 3GPP networks, in which the fact that the prefix is delegated to the
host is not explicit in the protocol signalling but unambiguously defined
by link-specific standards (i.e., 3GPP standards), which guarantees that
the prefix uniquely belongs to the host. I think there would be a benefit
if host behaviour could change based on such knowledge of the link
characteristics, and this document would be a good place to say so. RFC
7278 is an implicit case in which we are already taking advantage of those
characteristics.

On Fri, Jul 27, 2018 at 2:25 AM Ron Bonica <[email-masked]> wrote:

> Folks,
>
> This draft initiates a two week call for adoption on
> draft-templin-v6ops-pdhost. Please respond by August 9, 2018.
>
>                                                                      Ron
>
> _______________________________________________
> v6ops mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/v6ops
>

---

From: Fred Baker <[email-masked]>
Date: Fri, 27 Jul 2018 12:47:18 -0700

> On Jul 27, 2018, at 1:46 AM, Lorenzo Colitti <lorenzo=[email-masked]> wrote:
> 
> I have read the draft and support adoption. The document is a general discussion of how hosts can benefit from multiple addresses that is agnostic to the way the prefix is delivered, and it fits well with the spirit of RFC 7934.
> 
> I note that Section 8 seems to specify host behaviour, which is typically not in scope for v6ops. To my mind that doesn't preclude adoption since it can be reworded in a way that doesn't specify host behaviour but only specifies the consequences of potential changes to host behaviour that specified by other working groups such as 6man.
> 
> Section 10 should mention the de-facto prefix delegation mechanism used by all 3GPP networks, in which the fact that the prefix is delegated to the host is not explicit in the protocol signalling but unambiguously defined by link-specific standards (i.e., 3GPP standards), which guarantees that the prefix uniquely belongs to the host. I think there would be a benefit if host behaviour could change based on such knowledge of the link characteristics, and this document would be a good place to say so. RFC 7278 is an implicit case in which we are already taking advantage of those characteristics.

It would be good to have a reference, for the bibliography. What is the reference identifier etc?

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 28 Jul 2018 08:25:27 +1200

Support.

N.B. I think that probably the reference to draft-sun-casm-address-pool-management-yang should be replaced by draft-li-opsawg-address-pool-management-arch, which is more current although it doesn't include a YANG model.

Regards
   Brian

---

From: "Templin (US), Fred L" <[email-masked]>
Date: Mon, 30 Jul 2018 15:24:19 +0000

Hi Lorenzo,

Thank you for these comments. I can certainly reword Section 8 to avoid
language that would imply host specifications as you suggest. Also, I agree
it would be good to add the 3GPP example to Section 10.

I will put these on the TODO list for the next document version, but will
take cues from the working group chairs as to when a new version should
be issued.

Fred

From: v6ops [mailto:[email-masked]] On Behalf Of Lorenzo Colitti
Sent: Friday, July 27, 2018 1:46 AM
To: Ron Bonica <[email-masked]>
Cc: [email-masked] WG <[email-masked]>
Subject: Re: [v6ops] Call for Adoption: draft-templin-v6ops-pdhost

On Fri, Jul 27, 2018 at 2:25 AM Ron Bonica <[email-masked]<mailto:[email-masked]>> wrote:
Folks,

                                                                     Ron

_______________________________________________
v6ops mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/v6ops

---

From: "Templin (US), Fred L" <[email-masked]>
Date: Mon, 30 Jul 2018 15:31:46 +0000

Hi Fred,

I think the references for Lorenzo's comment would be RFC7066 and/or RFC7278.
Lorenzo - do I have that right?

Thanks - Fred

> -----Original Message-----
> From: v6ops [mailto:[email-masked]] On Behalf Of Fred Baker
> Sent: Friday, July 27, 2018 12:47 PM
> To: Lorenzo Colitti <lorenzo=[email-masked]>
> > I have read the draft and support adoption. The document is a general discussion of how hosts can benefit from multiple addresses
> that is agnostic to the way the prefix is delivered, and it fits well with the spirit of RFC 7934.
> >
> > I note that Section 8 seems to specify host behaviour, which is typically not in scope for v6ops. To my mind that doesn't preclude
> adoption since it can be reworded in a way that doesn't specify host behaviour but only specifies the consequences of potential
> changes to host behaviour that specified by other working groups such as 6man.
> >
> > Section 10 should mention the de-facto prefix delegation mechanism used by all 3GPP networks, in which the fact that the prefix is
> delegated to the host is not explicit in the protocol signalling but unambiguously defined by link-specific standards (i.e., 3GPP
> standards), which guarantees that the prefix uniquely belongs to the host. I think there would be a benefit if host behaviour could
> change based on such knowledge of the link characteristics, and this document would be a good place to say so. RFC 7278 is an implicit
> case in which we are already taking advantage of those characteristics.
>

---

From: "Templin (US), Fred L" <[email-masked]>
Date: Mon, 30 Jul 2018 15:32:28 +0000

Thanks Brian - this will be addressed in the next version.

Fred

> From: v6ops [mailto:[email-masked]] On Behalf Of Brian E Carpenter
> Sent: Friday, July 27, 2018 1:25 PM
> To: Ron Bonica <[email-masked]>; [email-masked]
> N.B. I think that probably the reference to draft-sun-casm-address-pool-management-yang should be replaced by draft-li-opsawg-
> address-pool-management-arch, which is more current although it doesn't include a YANG model.
> 
> Regards
>    Brian
>

---

From: Fred Baker <[email-masked]>
Date: Mon, 30 Jul 2018 08:34:53 -0700

> On Jul 30, 2018, at 8:31 AM, Templin (US), Fred L <[email-masked]> wrote:
> 
> Hi Fred,
> 

He was mentioning 3GPP specifications, if I understood him correctly.

---

From: "Templin (US), Fred L" <[email-masked]>
Date: Mon, 30 Jul 2018 15:43:24 +0000

Hi Fred,

RFC7066 and RFC7278 have 3GPP spec citations, but I am not sure which one
or ones would be the right ones. Can we inherit the 3GPP specs by citing the
RFCs, or do we need to go in and dig them out for inclusion in this document?

Thanks - Fred

> From: Fred Baker [mailto:[email-masked]]
> Sent: Monday, July 30, 2018 8:35 AM
> To: Templin (US), Fred L <[email-masked]>
> Cc: Lorenzo Colitti <lorenzo=[email-masked]>; [email-masked] WG <[email-masked]>

---

From: Fred Baker <[email-masked]>
Date: Mon, 30 Jul 2018 08:52:30 -0700

It sounded to me like Lorenzo was looking for the actual 3GPP specifications. However, that's really a question for him, not me.

draft-ietf-v6ops-rfc3316bis-06.xml, which became RFC 7066, contains:

  <reference anchor='TS.23060'>
   <front>
    <title>General Packet Radio Service (GPRS); Service description; Stage 2
    </title>
    <author><organization>3GPP</organization></author>
    <date day='7' month='March' year='2013' />
   </front>
   <seriesInfo name='3GPP TS' value='23.060 11.5.0' />
   <format type='HTML' target='http://www.3gpp.org/ftp/Specs/html-info/23060.htm' />
  </reference>

  <reference anchor='TS.29061'>
   <front>
    <title>Interworking between the Public Land Mobile Network (PLMN) supporting
           packet based services and Packet Data Networks (PDN)
    </title>
    <author><organization>3GPP</organization></author>
    <date day='15' month='March' year='2013' />
   </front>
   <seriesInfo name='3GPP TS' value='29.061 11.4.0' />
   <format type='HTML' target='http://www.3gpp.org/ftp/Specs/html-info/29061.htm' />
  </reference>

  <reference anchor='TS.23401'>
   <front>
    <title>General Packet Radio Service (GPRS) enhancements for Evolved
           Universal Terrestrial Radio Access Network (E-UTRAN) access
    </title>
    <author><organization>3GPP</organization></author>
    <date day='7' month='March' year='2013' />
   </front>
   <seriesInfo name='3GPP TS' value='23.401 11.5.0' />
   <format type='HTML' target='http://www.3gpp.org/ftp/Specs/html-info/23401.htm' />
  </reference>

  <reference anchor='TS.23402'>
   <front>
    <title>Architectural enhancements for non-3GPP accesses
    </title>
    <author><organization>3GPP</organization></author>
    <date day='8' month='March' year='2013' />
   </front>
   <seriesInfo name='3GPP TS' value='23.402 11.6.0' />
   <format type='HTML' target='http://www.3gpp.org/ftp/Specs/html-info/23402.htm' />
  </reference>

> On Jul 30, 2018, at 8:43 AM, Templin (US), Fred L <[email-masked]> wrote:
> 
> Hi Fred,
>

---

From: David Farmer <[email-masked]>
Date: Mon, 30 Jul 2018 11:41:00 -0500

I support the adoption of this draft.

-- 
===============================================
David Farmer               Email:[email-masked]
Networking & Telecommunication Services
Office of Information Technology
University of Minnesota
2218 University Ave SE        Phone: 612-626-0815
Minneapolis, MN 55414-3029   Cell: 612-812-9952
===============================================