Subject: [Dhcpv6bis] a primary list of possible RFCs/drafts to merge

From: Sheng Jiang <[email-masked]>
Date: Thu, 12 Dec 2013 02:48:37 +0000

Hi, all,

The below is a primary list of possible RFCs/drafts to merge, also available in attached txt. We should discuss them. For most of service configuration options, it may be easy to filter them out. In a quick glance, there are at least a few worthy out discussion.

RFC 3736 Stateless DHCPv6 Service
RFC 4580 DHCPv6 Relay Agent Subscriber-ID Option
RFC 4649 DHCPv6 Relay Agent Remote-ID Option
RFC 4994 DHCPv6 Relay Agent Echo Request Option
RFC 5007 DHCPv6 Leasequery
RFC 5460 DHCPv6 Bulk Leasequery
RFC 6221 Lightweight DHCPv6 Relay Agent
RFC 6355 Definition of the UUID-Based DHCPv6 Unique Identifier (DUID-UUID)
RFC 6422 Relay-Supplied DHCP Options
RFC 6603 Prefix Exclude Option for DHCPv6-based Prefix Delegation
RFC 6644 Rebind Capability in DHCPv6 Reconfigure Messages
RFC 6939 Client Link-Layer Address Option in DHCPv6
RFC 6977 Triggering DHCPv6 Reconfiguration from Relay Agents
RFC 7083 Modification to Default Values of SOL_MAX_RT and INF_MAX_RT

Regards,

Sheng

3c. prepare a list of possible RFCs/drafts to merge

RFC 3319 DHCPv6 Options for Session Initiation Protocol (SIP) Servers 
RFC 3646 DNS Configuration options for DHCPv6
RFC 3736 Stateless DHCPv6 Service
RFC 3898 Network Information Service (NIS) Configuration Options for DHCPv6
RFC 4075 Simple Network Time Protocol (SNTP) Configuration Option for DHCPv6
RFC 4242 Information Refresh Time Option for DHCPv6
RFC 4280 DHCP Options for Broadcast and Multicast Control Servers
RFC 4580 DHCPv6 Relay Agent Subscriber-ID Option
RFC 4649 DHCPv6 Relay Agent Remote-ID Option
RFC 4703 Resolution of Fully Qualified Domain Name (FQDN) Conflicts among DHCP Clients
RFC 4704 DHCPv6 Client Fully Qualified Domain Name (FQDN) Option
RFC 4776 DHCPv4 and DHCPv6 Option for Civic Addresses Configuration InformationRFC 4833 Timezone Options for DHCP
RFC 4994 DHCPv6 Relay Agent Echo Request Option
RFC 5007 DHCPv6 Leasequery
RFC 5192 DHCP Options for Protocol for Carrying Authentication for Network Access (PANA) Authentication Agents
RFC 5460 DHCPv6 Bulk Leasequery
RFC 5678 DHCPv4 and DHCPv6 Options for IEEE 802.21 Mobility Services (MoS) Discovery
RFC 5908 Network Time Protocol (NTP) Server Option for DHCPv6
RFC 5970 DHCPv6 Options for Network Boot
RFC 6153 DHCPv4 and DHCPv6 Options for Access Network Discovery and Selection Function (ANDSF) Discovery
RFC 6221 Lightweight DHCPv6 Relay Agent
RFC 6276 DHCPv6 Prefix Delegation for Network Mobility (NEMO)
RFC 6334 DHCPv6 Option for Dual-Stack Lite
RFC 6355 Definition of the UUID-Based DHCPv6 Unique Identifier (DUID-UUID)
RFC 6422 Relay-Supplied DHCP Options
RFC 6440 EAP Re-authentication Protocol (ERP) Local Domain Name DHCPv6 Option
RFC 6603 Prefix Exclude Option for DHCPv6-based Prefix Delegation
RFC 6607 Virtual Subnet Selection Options for DHCPv4 and DHCPv6
RFC 6644 Rebind Capability in DHCPv6 Reconfigure Messages
RFC 6653 DHCPv6 Prefix Delegation in Long-Term Evolution (LTE) Networks
RFC 6784 Kerberos Options for DHCPv6
RFC 6939 Client Link-Layer Address Option in DHCPv6
RFC 6977 Triggering DHCPv6 Reconfiguration from Relay Agents
RFC 7037 RADIUS Option for the DHCPv6 Relay Agent
RFC 7083 Modification to Default Values of SOL_MAX_RT and INF_MAX_RT

draft-ietf-dhc-topo-conf
draft-ietf-dhc-access-network-identifier
draft-ietf-dhc-dns-pd
draft-ietf-dhc-dhcpv6-unknown-msg
draft-ietf-dhc-sedhcpv6

---

From: Sheng Jiang <[email-masked]>
Date: Thu, 12 Dec 2013 03:04:24 +0000

Oops... The text become unreadable after sent out though outlook email editor. Please see the attached two txt documents. Also resent the roughly filtered list here. There are 6 document officially "update" RFC3315.

Rough filtered List

RFC 6221 (update RFC3315) Lightweight DHCPv6 Relay Agent 

RFC 6422 (update RFC3315) Relay-Supplied DHCP Options 

RFC 6644 (update RFC3315) Rebind Capability in DHCPv6 Reconfigure Messages 

RFC 7083 (update RFC3315) Modification to Default Values of SOL_MAX_RT and INF_MAX_RT

Another two documents that updated RFC3315

RFC 4361 Node-specific Client Identifiers for DHCPv4

RFC 5494 IANA Allocation Guidelines for the Address Resolution Protocol (ARP)

Regards,

Sheng

>-----Original Message-----
>From: Dhcpv6bis [mailto:[email-masked]] On Behalf Of Sheng
>Jiang
>Sent: Thursday, December 12, 2013 10:49 AM
>To: [email-masked]
>Subject: [Dhcpv6bis] a primary list of possible RFCs/drafts to merge
>
>Hi, all,
>
>The below is a primary list of possible RFCs/drafts to merge, also available in
>attached txt. We should discuss them. For most of service configuration
>options, it may be easy to filter them out. In a quick glance, there are at least
>a few worthy out discussion.
>
>RFC 4580 DHCPv6 Relay Agent Subscriber-ID Option RFC 4649 DHCPv6 Relay
>Agent Remote-ID Option RFC 4994 DHCPv6 Relay Agent Echo Request Option
>RFC 5007 DHCPv6 Leasequery RFC 5460 DHCPv6 Bulk Leasequery RFC 6221
>Lightweight DHCPv6 Relay Agent RFC 6355 Definition of the UUID-Based
>DHCPv6 Unique Identifier (DUID-UUID) RFC 6422 Relay-Supplied DHCP
>Options RFC 6603 Prefix Exclude Option for DHCPv6-based Prefix Delegation
>RFC 6644 Rebind Capability in DHCPv6 Reconfigure Messages RFC 6939 Client
>Link-Layer Address Option in DHCPv6 RFC 6977 Triggering DHCPv6
>Reconfiguration from Relay Agents RFC 7083 Modification to Default Values
>of SOL_MAX_RT and INF_MAX_RT
>
>Regards,
>
>Sheng
>
>RFC 3319 DHCPv6 Options for Session Initiation Protocol (SIP) Servers RFC
>3646 DNS Configuration options for DHCPv6 RFC 3736 Stateless DHCPv6
>Service RFC 3898 Network Information Service (NIS) Configuration Options
>for DHCPv6 RFC 4075 Simple Network Time Protocol (SNTP) Configuration
>Option for DHCPv6 RFC 4242 Information Refresh Time Option for DHCPv6
>RFC 4280 DHCP Options for Broadcast and Multicast Control Servers RFC 4580
>DHCPv6 Relay Agent Subscriber-ID Option RFC 4649 DHCPv6 Relay Agent
>Remote-ID Option RFC 4703 Resolution of Fully Qualified Domain Name
>(FQDN) Conflicts among DHCP Clients RFC 4704 DHCPv6 Client Fully Qualified
>Domain Name (FQDN) Option RFC 4776 DHCPv4 and DHCPv6 Option for Civic
>Addresses Configuration InformationRFC 4833 Timezone Options for DHCP
>RFC 4994 DHCPv6 Relay Agent Echo Request Option RFC 5007 DHCPv6
>Leasequery RFC 5192 DHCP Options for Protocol for Carrying Authentication
>for Network Access (PANA) Authentication Agents RFC 5460 DHCPv6 Bulk
>Leasequery RFC 5678 DHCPv4 and DHCPv6 Options for IEEE 802.21 Mobility
>Services (MoS) Discovery RFC 5908 Network Time Protocol (NTP) Server
>Option for DHCPv6 RFC 5970 DHCPv6 Options for Network Boot RFC 6153
>DHCPv4 and DHCPv6 Options for Access Network Discovery and Selection
>Function (ANDSF) Discovery RFC 6221 Lightweight DHCPv6 Relay Agent RFC
>6276 DHCPv6 Prefix Delegation for Network Mobility (NEMO) RFC 6334
>DHCPv6 Option for Dual-Stack Lite RFC 6355 Definition of the UUID-Based
>DHCPv6 Unique Identifier (DUID-UUID) RFC 6422 Relay-Supplied DHCP
>Options RFC 6440 EAP Re-authentication Protocol (ERP) Local Domain Name
>DHCPv6 Option RFC 6603 Prefix Exclude Option for DHCPv6-based Prefix
>Delegation RFC 6607 Virtual Subnet Selection Options for DHCPv4 and
>DHCPv6 RFC 6644 Rebind Capability in DHCPv6 Reconfigure Messages RFC
>6653 DHCPv6 Prefix Delegation in Long-Term Evolution (LTE) Networks RFC
>6784 Kerberos Options for DHCPv6 RFC 6939 Client Link-Layer Address Option
>in DHCPv6 RFC 6977 Triggering DHCPv6 Reconfiguration from Relay Agents
>RFC 7037 RADIUS Option for the DHCPv6 Relay Agent RFC 7083 Modification
>to Default Values of SOL_MAX_RT and INF_MAX_RT
>
>draft-ietf-dhc-topo-conf

---

From: "Leaf Yeh" <[email-masked]>
Date: Thu, 12 Dec 2013 12:36:44 +0800

Sounds the target turns to be bigger...

Best Regards,
Leaf

-----Original Message-----
From: Dhcpv6bis [mailto:[email-masked]] On Behalf Of Sheng Jiang
Sent: Thursday, December 12, 2013 10:49 AM
To: [email-masked]
Subject: [Dhcpv6bis] a primary list of possible RFCs/drafts to merge

Hi, all,

RFC 3736 Stateless DHCPv6 Service
RFC 4580 DHCPv6 Relay Agent Subscriber-ID Option RFC 4649 DHCPv6 Relay Agent Remote-ID Option RFC 4994 DHCPv6 Relay Agent Echo Request Option RFC 5007 DHCPv6 Leasequery RFC 5460 DHCPv6 Bulk Leasequery RFC 6221 Lightweight DHCPv6 Relay Agent RFC 6355 Definition of the UUID-Based DHCPv6 Unique Identifier (DUID-UUID) RFC 6422 Relay-Supplied DHCP Options RFC 6603 Prefix Exclude Option for DHCPv6-based Prefix Delegation RFC 6644 Rebind Capability in DHCPv6 Reconfigure Messages RFC 6939 Client Link-Layer Address Option in DHCPv6 RFC 6977 Triggering DHCPv6 Reconfiguration from Relay Agents RFC 7083 Modification to Default Values of SOL_MAX_RT and INF_MAX_RT

Regards,

Sheng

RFC 3319 DHCPv6 Options for Session Initiation Protocol (SIP) Servers RFC 3646 DNS Configuration options for DHCPv6 RFC 3736 Stateless DHCPv6 Service RFC 3898 Network Information Service (NIS) Configuration Options for DHCPv6 RFC 4075 Simple Network Time Protocol (SNTP) Configuration Option for DHCPv6 RFC 4242 Information Refresh Time Option for DHCPv6 RFC 4280 DHCP Options for Broadcast and Multicast Control Servers RFC 4580 DHCPv6 Relay Agent Subscriber-ID Option RFC 4649 DHCPv6 Relay Agent Remote-ID Option RFC 4703 Resolution of Fully Qualified Domain Name (FQDN) Conflicts among DHCP Clients RFC 4704 DHCPv6 Client Fully Qualified Domain Name (FQDN) Option RFC 4776 DHCPv4 and DHCPv6 Option for Civic Addresses Configuration InformationRFC 4833 Timezone Options for DHCP RFC 4994 DHCPv6 Relay Agent Echo Request Option RFC 5007 DHCPv6 Leasequery RFC 5192 DHCP Options for Protocol for Carrying Authentication for Network Access (PANA) Authentication Agents RFC 5460 DHCPv6 Bulk Leasequery RFC 5678 DHCPv4 and DHCPv6 Options for IEEE 802.21 Mobility Services (MoS) Discovery RFC 5908 Network Time Protocol (NTP) Server Option for DHCPv6 RFC 5970 DHCPv6 Options for Network Boot RFC 6153 DHCPv4 and DHCPv6 Options for Access Network Discovery and Selection Function (ANDSF) Discovery RFC 6221 Lightweight DHCPv6 Relay Agent RFC 6276 DHCPv6 Prefix Delegation for Network Mobility (NEMO) RFC 6334 DHCPv6 Option for Dual-Stack Lite RFC 6355 Definition of the UUID-Based DHCPv6 Unique Identifier (DUID-UUID) RFC 6422 Relay-Supplied DHCP Options RFC 6440 EAP Re-authentication Protocol (ERP) Local Domain Name DHCPv6 Option RFC 6603 Prefix Exclude Option for DHCPv6-based Prefix Delegation RFC 6607 Virtual Subnet Selection Options for DHCPv4 and DHCPv6 RFC 6644 Rebind Capability in DHCPv6 Reconfigure Messages RFC 6653 DHCPv6 Prefix Delegation in Long-Term Evolution (LTE) Networks RFC 6784 Kerberos Options for DHCPv6 RFC 6939 Client Link-Layer Address Option in DHCPv6 RFC 6977 Triggering DHCPv6 Reconfiguration from Relay Agents RFC 7037 RADIUS Option for the DHCPv6 Relay Agent RFC 7083 Modification to Default Values of SOL_MAX_RT and INF_MAX_RT

draft-ietf-dhc-topo-conf

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Thu, 12 Dec 2013 04:46:52 +0000

Thanks Sheng for the list. We will need to look over these in more detail, but ...

IMHO ...

We will NOT be doing most of these. In some cases, we may just add basic information and a reference (such as for DUID-UUID).

I do think SOLMAX (RFC 7083) and Reconfigure REBIND (RFC 6644) are probably worth incorporating.

(As I mentioned on the call) I did email Ralph about RFC 3736 and he agreed with me (as we had talked about it a while back) that a section on what's needed for a minimal DHCPv6 service ('other configuration' only). I attached that email from Ralph as it wasn't to the full group.

RFC 6221 is an interesting question and that one needs review and some thought.

RFC 6422, at least taking a quick look, I think was mislabeled as updates 3315 (though there is some subtle change in server processing). But I think this stands on its own.

RFC 4361 was another I think was incorrectly labeled as updates 3315 - what in it updates 3315? And similar for RFC 5494.

Those that really update RFC 3315 will require some additional review to see what they change and whether to add some basic information and reference the document or whether to incorporate more of the changes.

Simple option RFCs will be left as is and not included.

---

We will need to think about how to handle 'documenting' our conclusions on these? Do we want to create issues for each or groups of documents (i.e., one for all the simple options that we are not including)? And perhaps a separate issue for those that specifically update 3315 so we can discuss and document our decision?

- Bernie

-----Original Message-----
From: Dhcpv6bis [mailto:[email-masked]] On Behalf Of Sheng Jiang
Sent: Wednesday, December 11, 2013 10:04 PM
To: [email-masked]
Subject: Re: [Dhcpv6bis] a primary list of possible RFCs/drafts to merge

Rough filtered List

Regards,

Sheng

>The below is a primary list of possible RFCs/drafts to merge, also 
>available in attached txt. We should discuss them. For most of service 
>configuration options, it may be easy to filter them out. In a quick 
>glance, there are at least a few worthy out discussion.
>
>Options RFC 6603 Prefix Exclude Option for DHCPv6-based Prefix 
>Delegation RFC 6644 Rebind Capability in DHCPv6 Reconfigure Messages 
>RFC 6939 Client Link-Layer Address Option in DHCPv6 RFC 6977 Triggering 
>DHCPv6 Reconfiguration from Relay Agents RFC 7083 Modification to 
>Default Values of SOL_MAX_RT and INF_MAX_RT
>
>Regards,
>
>Sheng
>
>RFC
>Service RFC 3898 Network Information Service (NIS) Configuration 
>Options for DHCPv6 RFC 4075 Simple Network Time Protocol (SNTP) 
>Configuration Option for DHCPv6 RFC 4242 Information Refresh Time 
>Option for DHCPv6 RFC 4280 DHCP Options for Broadcast and Multicast 
>Control Servers RFC 4580
>(FQDN) Conflicts among DHCP Clients RFC 4704 DHCPv6 Client Fully 
>Qualified Domain Name (FQDN) Option RFC 4776 DHCPv4 and DHCPv6 Option 
>for Civic Addresses Configuration InformationRFC 4833 Timezone Options 
>for DHCP RFC 4994 DHCPv6 Relay Agent Echo Request Option RFC 5007 
>DHCPv6 Leasequery RFC 5192 DHCP Options for Protocol for Carrying 
>Authentication for Network Access (PANA) Authentication Agents RFC 5460 
>DHCPv6 Bulk Leasequery RFC 5678 DHCPv4 and DHCPv6 Options for IEEE 
>802.21 Mobility Services (MoS) Discovery RFC 5908 Network Time Protocol 
>(NTP) Server Option for DHCPv6 RFC 5970 DHCPv6 Options for Network Boot 
>RFC 6153
>6784 Kerberos Options for DHCPv6 RFC 6939 Client Link-Layer Address 
>Option in DHCPv6 RFC 6977 Triggering DHCPv6 Reconfiguration from Relay 
>Agents RFC 7037 RADIUS Option for the DHCPv6 Relay Agent RFC 7083 
>Modification to Default Values of SOL_MAX_RT and INF_MAX_RT
>
>draft-ietf-dhc-topo-conf
_______________________________________________
Dhcpv6bis mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dhcpv6bis

Subject: Re: RFC 3736 and the RFC 3315/3633bis work
From: "Ralph Droms (rdroms)" <[email-masked]>
To: "Bernie Volz (volz)" <[email-masked]>
Cc: "Tomek Mrugalski ([email-masked])" <[email-masked]>
Date: Fri, 6 Dec 2013 19:30:39 +0000

On Dec 2, 2013, at 12:35 PM 12/2/13, Bernie Volz (volz) <[email-masked]> wrote:

> Ralph:
>
> What are your feelings about RFC 3736 as we do the RFC 3315/3633 bits work?
>
> Should we mostly ignore it?

Yes.  I wrote it mostly to shut up, um, respond to all the FUD about how heavyweight DHCPv6 is.
>
> Is there any portion of this document that should end up in the bis document?
>
> Perhaps we should consider a section in the bis document on a “minimal DHCPv6” deployment for stateless (or something like that), which would outline that for the “O – Other Configuration” mode you really only need a server that handles Information-Request/Reply?

Sure, a section to that effect wouldn't hurt.

- Ralph

> -          Bernie

---

From: Sheng Jiang <[email-masked]>
Date: Thu, 12 Dec 2013 05:57:15 +0000

Hi, Bernie,

Your reply is exactly what I expected. We could not take that much into one single document. That's why I call it primary list, which is just a kick off for us to figure out the real incorporating work.

Could you comment on one more document: RFC 6603 (update RFC3633) Prefix Exclude Option for DHCPv6-based Prefix Delegation?

Best regards,

Sheng

>From: Dhcpv6bis [mailto:[email-masked]] On Behalf Of Bernie
>Volz (volz)
>Sent: Thursday, December 12, 2013 12:47 PM
>To: Sheng Jiang; [email-masked]
>We will NOT be doing most of these. In some cases, we may just add basic
>information and a reference (such as for DUID-UUID).
>
>(As I mentioned on the call) I did email Ralph about RFC 3736 and he agreed
>with me (as we had talked about it a while back) that a section on what's
>needed for a minimal DHCPv6 service ('other configuration' only). I attached
>that email from Ralph as it wasn't to the full group.
>
>RFC 6422, at least taking a quick look, I think was mislabeled as updates 3315
>(though there is some subtle change in server processing). But I think this
>stands on its own.
>
>RFC 4361 was another I think was incorrectly labeled as updates 3315 - what
>in it updates 3315? And similar for RFC 5494.
>
>Those that really update RFC 3315 will require some additional review to see
>what they change and whether to add some basic information and reference
>the document or whether to incorporate more of the changes.
>
>We will need to think about how to handle 'documenting' our conclusions on
>these? Do we want to create issues for each or groups of documents (i.e.,
>one for all the simple options that we are not including)? And perhaps a
>separate issue for those that specifically update 3315 so we can discuss and
>document our decision?
>
>- Bernie
>
>Oops... The text become unreadable after sent out though outlook email
>editor. Please see the attached two txt documents. Also resent the roughly
>filtered list here. There are 6 document officially "update" RFC3315.
>
>Rough filtered List
>

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Thu, 12 Dec 2013 14:49:59 +0000

Without looking at RFC 6603 again and working just from memory, I think we just clean up the some of the text related to how the delegated prefix could be used that was adjusted by RFC 6603, but the Prefix Exclude option would be left to be in 6603 not in 3315bis.

We really should take the stand that we NOT add/change anything to 3315/3633bis unless text in the original 3315/3633 is invalidated or corrected by a later RFC (or RFC to be - assuming it is well along), and then just to update the 3315/3633 text accordingly (with reference to the RFC for more details).

This is NOT a project to write one document that includes all of DHCPv6 (all options, all new messages, etc.). The project is just to combine 3315/3633 and do cleanup to those documents related to the core DHCPv6 protocol.

- Bernie (from iPad)

-----Original Message-----
From: Sheng Jiang [mailto:[email-masked]] 
Sent: Thursday, December 12, 2013 12:57 AM
To: Bernie Volz (volz); [email-masked]
Subject: RE: a primary list of possible RFCs/drafts to merge

Hi, Bernie,

Best regards,

Sheng

>We will NOT be doing most of these. In some cases, we may just add 
>basic information and a reference (such as for DUID-UUID).
>
>(As I mentioned on the call) I did email Ralph about RFC 3736 and he 
>agreed with me (as we had talked about it a while back) that a section 
>on what's needed for a minimal DHCPv6 service ('other configuration' 
>only). I attached that email from Ralph as it wasn't to the full group.
>
>RFC 6422, at least taking a quick look, I think was mislabeled as 
>updates 3315 (though there is some subtle change in server processing). 
>But I think this stands on its own.
>
>RFC 4361 was another I think was incorrectly labeled as updates 3315 - 
>what in it updates 3315? And similar for RFC 5494.
>
>Those that really update RFC 3315 will require some additional review 
>to see what they change and whether to add some basic information and 
>reference the document or whether to incorporate more of the changes.
>
>We will need to think about how to handle 'documenting' our conclusions 
>on these? Do we want to create issues for each or groups of documents 
>(i.e., one for all the simple options that we are not including)? And 
>perhaps a separate issue for those that specifically update 3315 so we 
>can discuss and document our decision?
>
>- Bernie
>
>editor. Please see the attached two txt documents. Also resent the 
>roughly filtered list here. There are 6 document officially "update" RFC3315.
>
>Rough filtered List
>

---

From: Sheng Jiang <[email-masked]>
Date: Fri, 13 Dec 2013 08:57:09 +0000

>probably worth incorporating.

If we all agree this, I can add two new tickets into the DHCPv6bis issuetracker.

As the editor of RFC6644, I do have the last xml file before publishing. It just needs minimum work to become the official RFC form.

Regards,

Sheng

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Fri, 13 Dec 2013 12:30:49 +0000

I don't think we need to get final forms of other rfcs that we will "merge" in unless there will be lots of text. I think both of these are minor changes to 3315? We don't have to provide a lot of the background since we can still reference original rfc.

- Bernie (from iPad)

---

From: "Leaf Yeh" <[email-masked]>
Date: Sat, 14 Dec 2013 11:50:26 +0800

I guess draft-ietf-dhc-dhcpv6-unknown-msg-03 (Handling Unknown DHCPv6
Messages) sounds in the scope of DHCPv6bis. Right? If yes, I bet you still
have interest to publish it.

Best Regards,
Leaf

-----Original Message-----
From: Dhcpv6bis [mailto:[email-masked]] On Behalf Of Bernie Volz
(volz)
Sent: Thursday, December 12, 2013 10:50 PM
To: Sheng Jiang; [email-masked]
Subject: Re: [Dhcpv6bis] a primary list of possible RFCs/drafts to merge

Without looking at RFC 6603 again and working just from memory, I think we
just clean up the some of the text related to how the delegated prefix could
be used that was adjusted by RFC 6603, but the Prefix Exclude option would
be left to be in 6603 not in 3315bis.

We really should take the stand that we NOT add/change anything to
3315/3633bis unless text in the original 3315/3633 is invalidated or
corrected by a later RFC (or RFC to be - assuming it is well along), and
then just to update the 3315/3633 text accordingly (with reference to the
RFC for more details).

This is NOT a project to write one document that includes all of DHCPv6 (all
options, all new messages, etc.). The project is just to combine 3315/3633
and do cleanup to those documents related to the core DHCPv6 protocol.

- Bernie (from iPad)

-----Original Message-----
From: Sheng Jiang [mailto:[email-masked]]
Sent: Thursday, December 12, 2013 12:57 AM
To: Bernie Volz (volz); [email-masked]
Subject: RE: a primary list of possible RFCs/drafts to merge

Hi, Bernie,

Your reply is exactly what I expected. We could not take that much into one
single document. That's why I call it primary list, which is just a kick off
for us to figure out the real incorporating work.

Could you comment on one more document: RFC 6603 (update RFC3633) Prefix
Exclude Option for DHCPv6-based Prefix Delegation?

Best regards,

Sheng

---

From: "Leaf Yeh" <[email-masked]>
Date: Sat, 14 Dec 2013 12:03:12 +0800

I bet the text to be revised if we don't reference RFC6644 will be less than
the text to reference that RFC. :-)

Best Regards,
Leaf

-----Original Message-----
From: Dhcpv6bis [mailto:[email-masked]] On Behalf Of Bernie Volz
(volz)
Sent: Friday, December 13, 2013 8:31 PM
To: Sheng Jiang
Cc: [email-masked]
Subject: Re: [Dhcpv6bis] a primary list of possible RFCs/drafts to merge

I don't think we need to get final forms of other rfcs that we will "merge"
in unless there will be lots of text. I think both of these are minor
changes to 3315? We don't have to provide a lot of the background since we
can still reference original rfc.

- Bernie (from iPad)

On Dec 13, 2013, at 3:57 AM, "Sheng Jiang" <[email-masked]> wrote:

> As the editor of RFC6644, I do have the last xml file before publishing.
It just needs minimum work to become the official RFC form.

---

From: Michael Richardson <[email-masked]>
Date: Tue, 17 Dec 2013 13:48:24 -0500

I just fixed the XML for section 4 and I'll do section 5 (the tables).
I think that all the diagrams are okay, but I'm checking the whole
document to be sure, which is why I saw the tables.

I propose, once we are happy that we have reflected 3315 properly into xml,
that we change some of the teminology section, specifically, I propose we
change:

            <t hangText="Identity association for non-temporary addresses
            (IA_NA)"> An IA that
            carries assigned addresses that are not temporary addresses (see
            "identity association for temporary addresses")</t>

which formats as:

      Identity association for non-temporary addresses (IA_NA) An IA
                                that carries assigned addresses that are
                                not temporary addresses (see "identity
                                association for temporary addresses")

(notice how IA_NA is basically lost)

to read instead:

      IA_NA                     An Identity Association (IA) for
                                Non-temporary Addresses (IA_NA). This IA
                                carries assigned addresses that are
                                not temporary addresses (see "IA_TA")

my experience is that "IA_NA" is a term, not
      "Identity association for non-temporary addresses"

===

My second proposal is that we publish the unchanged rfc3315bis as an ID-00,
and then start with editorial changes only in -01.  This will let us leverage
the rfcdiff tools and the like, and will let us ask to the WG to confirm that
we have not lost anything.

We will need to insert something useful into the authors section in order
to be able to post.

--
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting for hire =-

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Tue, 17 Dec 2013 20:41:46 +0000

Hi Michael:

Yes, I fixed all of the diagrams with my changes. It is indeed the 'hanging' text and lists that are still an issue.

The one difference with the diagrams it that I followed (I think) your convention of including a name which had not been done in the original RFC 3315. But I figured that was OK (though we may want to review the names at some point).

In going through it I agree there are a lot of minor fixes we can make (there are many places in the option definitions where things end or do not end with a period in the field definitions, etc.). I'm not sure if perhaps the RFC editor had conventions here that were followed or whether this was something they copied from the draft.

But, I held off on those changes as best we minimize differences for the -00. I agree that it would not be bad to publish -00 once we are done with cleanup and BEFORE we make any changes.

One question will be whether to publish -00 as a WG (draft-ietf-dhc) document or not. I would say we do as I think the WG has implicitly accepted to do this work but will check with Ted if that is acceptable (worst case we may have to ask the list to see if anyone would object).

We may want to start adding issues we find to the issue tracker?

- Bernie

-----Original Message-----
From: Dhcpv6bis [mailto:[email-masked]] On Behalf Of Michael Richardson
Sent: Tuesday, December 17, 2013 1:48 PM
To: [email-masked]
Subject: [Dhcpv6bis] some editorial decisions and process thoughts

I just fixed the XML for section 4 and I'll do section 5 (the tables).
I think that all the diagrams are okay, but I'm checking the whole document to be sure, which is why I saw the tables.

I propose, once we are happy that we have reflected 3315 properly into xml, that we change some of the teminology section, specifically, I propose we
change:

which formats as:

to read instead:

===

My second proposal is that we publish the unchanged rfc3315bis as an ID-00, and then start with editorial changes only in -01.  This will let us leverage the rfcdiff tools and the like, and will let us ask to the WG to confirm that we have not lost anything.

We will need to insert something useful into the authors section in order to be able to post.

--
Michael Richardson <[email-masked]>, Sandelman Software Works  -= IPv6 IoT consulting for hire =-

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Tue, 17 Dec 2013 21:11:50 +0000

One issue with publishing this is what do we call it and how do we handle 3633 if we also wanted to publish that for the record?

One option is not to publish 3633 at all. Another would be to publish both, 3315bis as a WG document and 3633base as an individual (which we would abandon)?

Perhaps best to discuss in a meeting in January once we have both done?

---

Michael, with respect to RFC 3315, I assume you have the pen. Let me know if there is more you need me to do. Once you are done, I can review the result to see what, if anything, is missing.

- Bernie

-----Original Message-----
From: Dhcpv6bis [mailto:[email-masked]] On Behalf Of Bernie Volz (volz)
Sent: Tuesday, December 17, 2013 3:42 PM
To: Michael Richardson; [email-masked]
Subject: Re: [Dhcpv6bis] some editorial decisions and process thoughts

Hi Michael:

- Bernie

-----Original Message-----
From: Dhcpv6bis [mailto:[email-masked]] On Behalf Of Michael Richardson
Sent: Tuesday, December 17, 2013 1:48 PM
To: [email-masked]
Subject: [Dhcpv6bis] some editorial decisions and process thoughts

which formats as:

to read instead:

===

---

From: Michael Richardson <[email-masked]>
Date: Wed, 18 Dec 2013 11:47:38 -0500

Bernie Volz (volz) <[email-masked]> wrote:
    > The one difference with the diagrams it that I followed (I think) your
    > convention of including a name which had not been done in the original
    > RFC 3315. But I figured that was OK (though we may want to review the
    > names at some point).

I agree.

    > In going through it I agree there are a lot of minor fixes we can make
    > (there are many places in the option definitions where things end or do
    > not end with a period in the field definitions, etc.). I'm not sure if
    > perhaps the RFC editor had conventions here that were followed or
    > whether this was something they copied from the draft.

I think that the rfc-editor did this in their nroff templates, if it hadn't
been done in the document.  We could ask them.

    > But, I held off on those changes as best we minimize differences for
    > the -00. I agree that it would not be bad to publish -00 once we are
    > done with cleanup and BEFORE we make any changes.

okay, when we do do this?

    > One question will be whether to publish -00 as a WG (draft-ietf-dhc)
    > document or not. I would say we do as I think the WG has implicitly
    > accepted to do this work but will check with Ted if that is acceptable
    > (worst case we may have to ask the list to see if anyone would
    > object).

    > We may want to start adding issues we find to the issue tracker?

okay. If I open editorial tickets, I guess the mailing list will get
notified, so it would be good to have something for people to see.

Bernie Volz (volz) <[email-masked]> wrote:
    > One issue with publishing this is what do we call it and how do we
    > handle 3633 if we also wanted to publish that for the record?

sorry, are you asking, should we do 3633bis?
or are you asking, should we roll 3633 into 3315bis?

    > One option is not to publish 3633 at all. Another would be to publish
    > both, 3315bis as a WG document and 3633base as an individual (which we
    > would abandon)?

I'm confused because 3633 is already published, so I think you mean 3633bis.

    > Michael, with respect to RFC 3315, I assume you have the pen.

okay.

--
]               Never tell me the odds!                 | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works        | network architect  [
]     [email-masked]  http://www.sandelman.ca/        |   ruby on rails    [

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Wed, 18 Dec 2013 18:13:07 +0000

See below (BV>).

- Bernie

-----Original Message-----
From: Dhcpv6bis [mailto:[email-masked]] On Behalf Of Michael Richardson
Sent: Wednesday, December 18, 2013 11:48 AM
To: Bernie Volz (volz)
Cc: [email-masked]
Subject: Re: [Dhcpv6bis] some editorial decisions and process thoughts

I agree.

    > whether this was something they copied from the draft.

I think that the rfc-editor did this in their nroff templates, if it hadn't been done in the document.  We could ask them.

okay, when we do do this?
BV> After we all agree that the RFC 3315bis matches RFC 3315 as closely as possible (i.e., after we publish -00).

    > We may want to start adding issues we find to the issue tracker?

okay. If I open editorial tickets, I guess the mailing list will get notified, so it would be good to have something for people to see.

BV> These are dhcpv6bis tickets so only 'we' will see the email. But as people can subscribe to the mail list or view the tickets, they can see the issues as well.

BV> I am saying if we make the 3315bis-00 (which should match RFC 3315) do we also want to publish a 3633bis-00 (which should match RFC 3633) or not. I don't think we need to because we are not going to issue a 3633bis document - just a revised 3315 which includes 3633.

BV> Yes.

okay.