Subject: Re: [Dhcpv6bis] [dhcpv6bis] #133 (XML 3315): Update abstract

From: Tomek Mrugalski <[email-masked]>
Date: Tue, 2 Feb 2016 14:33:08 +0100

I'm afraid the updated abstract text requires some further work.
Abstract referred to the protocol as DHCP, while the rest of the
document uses DHCPv6, so I updated it.

      This document describes the Dynamic Host Configuration Protocol
      for IPv6 (DHCPv6): an extensible mechanism for configuring hosts
      with network configuration parameters, IP addresses, and
      prefixes.  Parameters can be provided statelessly, or in
      combination with stateful assignment of one or more IPv6
      addresses and/or IPv6 prefixes.  DHCPv6 can operate either in
      place of or in addition to stateless address autoconfiguration
      (SLAAC).

      This document updates RFC 3315, the original DHCPv6
      specification, and incorporates the stateless DHCPv6 extensions
      (RFC 3736) and prefix delegation (RFC 3633), clarifying the
      interactions between these modes of operation (RFC 7550) and
      providing a mechanism for throttling DHCPv6 clients when DHCPv6
      service is not available (RFC 7083).

The problem with the second paragraph is that it says 'updates', while
we actually obsoleting the old specs. This raised a warning with idnits.
I think the warning is valid. People could easily be confused. How about
this change:

This document contains the updated text from RFC 3315, the original
DHCPv6 specification, and incorporates the stateless DHCPv6 extensions
(RFC 3736) and prefix delegation (RFC 3633), clarifying the
interactions between these modes of operation (RFC 7550) and
providing a mechanism for throttling DHCPv6 clients when DHCPv6
service is not available (RFC 7083). As such, RFC3315, RFC3633, RFC3736,
RFC7083 and RFC7550 are obsoleted.

Would that be ok? If so, I can do the update and publish -03. Everything
else seems to be done already. That's the only outstanding item. If you
think that it requires further discussion that we won't be able to wrap
up until tomorrow's meeting, please let me know and I'll upload -03 in
its current state.

Tomek

---

From: Dan Seibel <[email-masked]>
Date: Tue, 2 Feb 2016 06:55:14 -0700

I like the change and it removes a possible point of confusion.

> On Feb 2, 2016, at 6:33 AM, Tomek Mrugalski <[email-masked]> wrote:
> 
> _______________________________________________
> Dhcpv6bis mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dhcpv6bis

---

From: Ted Lemon <[email-masked]>
Date: Tue, 2 Feb 2016 14:07:47 +0000

> RFC7083 and RFC7550 are obsoleted.

I think this is fine except I would leave out the last sentence, since it's covered in the metadata.

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Tue, 2 Feb 2016 16:36:46 +0000

Either way (with or without the last sentence) is OK with me. (I vaguely recall that someone or something wants the RFCs in the text even if in the metadata.)

BTW: On the datatracker, RFC 3315 has: "Updated by RFC4361, RFC5494, RFC6221, RFC6422, RFC6644, RFC7083, RFC7227, RFC7283, RFC7550"

We might want to through all of those RFCs and make sure that their updates are incorporated. I'll open a ticket for this?

RFC 4361 (was draft-ietf-dhc-3315id-for-v4) 
Node-specific Client Identifiers for Dynamic Host Configuration Protocol Version Four (DHCPv4)

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

RFC 6221 - Lightweight DHCPv6 Relay Agent

RFC 6422 - Relay-Supplied DHCP Options

RFC 6644 - Rebind Capability in DHCPv6 Reconfigure Messages

RFC 7283 - Handling Unknown DHCPv6 Messages

Probably not a bad idea for us to at least incorporate RFC 6644 & 7283 and obsolete those?

- Bernie

-----Original Message-----
From: Dhcpv6bis [mailto:[email-masked]] On Behalf Of Ted Lemon
Sent: Tuesday, February 02, 2016 9:08 AM
To: Tomek Mrugalski <[email-masked]>; [email-masked]
Subject: Re: [Dhcpv6bis] [dhcpv6bis] #133 (XML 3315): Update abstract

> interactions between these modes of operation (RFC 7550) and providing 
> a mechanism for throttling DHCPv6 clients when DHCPv6 service is not 
> available (RFC 7083). As such, RFC3315, RFC3633, RFC3736,

---

From: Tomek Mrugalski <[email-masked]>
Date: Tue, 2 Feb 2016 18:34:19 +0100

On 02.02.2016 15:07, Ted Lemon wrote:
>> This document contains the updated text from RFC 3315, the
>> original DHCPv6 specification, and incorporates the stateless
>> DHCPv6 extensions (RFC 3736) and prefix delegation (RFC 3633),
>> clarifying the interactions between these modes of operation (RFC
>> 7550) and providing a mechanism for throttling DHCPv6 clients when
>> DHCPv6 service is not available (RFC 7083). As such, RFC3315,
>> RFC3633, RFC3736, RFC7083 and RFC7550 are obsoleted.
> 
Am afraid idnits has a different opinion. Besides the header, the
documents that are updated or obsoleted must be explicitly mentioned in
the abstract or introduction. Without the last sentence, there are 5
warnings produced, one for each RFC.

People seem to be fine with this change. I'm applying them now and
uploading -03 in couple minutes.

Tomek