Subject: Re: [dhcwg] WGLC for draft-ietf-dhc-topo-conf-03.txt - Respond by Oct 13, 2014

From: "Bernie Volz (volz)" <[email-masked]>
Date: Tue, 7 Oct 2014 03:07:11 +0000

Reminder that this WGLC is in progress and needs responses to advance. Please review and provide your support or reasons as to why you feel this is not ready yet or should never advance.

- Bernie (from iPad)

On Sep 29, 2014, at 10:36 AM, Bernie Volz (volz) <[email-masked]<mailto:[email-masked]>> wrote:

Hi all,

This message starts the DHC working group last call to advance "Customizing DHCP Configuration on the Basis of Network Topology”, draft-ietf-dhc-topo-conf-03, document as an Informational RFC. The authors believe that this version is ready.

The draft is available here:

http://tools.ietf.org/html/draft-ietf-dhc-topo-conf-03

Please send your comments by October 13th, 2014. If you do not feel this document should advance, please state your reasons why.

There are no IPR claims reported at this time.

Bernie Volz is the assigned shepherd for this document.

- Tomek & Bernie

---

From: Tomek Mrugalski <[email-masked]>
Date: Tue, 07 Oct 2014 16:46:27 +0200

On 29/09/14 16:36, Bernie Volz (volz) wrote:
> Please send your comments by October 13th, 2014. If you do not feel this
> document should advance, please state your reasons why.
As a co-author, I support this I-D moving forward.

This draft received quite a lot of reviews in its -01 version (thanks
again). Can I ask people who did the review back then (Andre, Carsten,
Simon, Jinmei and Suresh) to double check that all your comments were
addressed?

Thanks,
Tomek

---

From: JF Tremblay <[email-masked]>
Date: Tue, 7 Oct 2014 11:11:26 -0400

I’ve read draft-ietf-dhc-topo-conf-03 and found it useful and ready to go. 

Some text (last sentence of page 5 for example) seem to imply that “non-link local == global” and skip cases where ULA could be used, but this is minor. I don’t think anyone using ULAs on links would have a problem implementing this. 

Section 9 could have been a little bit more detailed, but I guess it would be hard without getting the rathole of implementation specific details. IMHO scenarios where multiple subnets are assigned to a link are a bit more common that the text suggests, but I’m not suggesting changing anything in this section. 

Found a single nit, section 9, second paragraph: 
"To support such an configuration”: s/an/a/

Also, interesting choice of wording in the IANA section… ;) 

JF

On Oct 7, 2014, at 10:46 AM, Tomek Mrugalski <[email-masked]> wrote:

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

---

From: Marcin Siodelski <[email-masked]>
Date: Mon, 13 Oct 2014 13:50:56 +0200

I have read the draft, I think it is useful work and I support it move
forward.

A couple of comments, mostly editorial. There is nothing really major.

Section 3: The title of this section sounds ambiguous. IMO, the better
name would be "Identifying Client's Location by DHCP servers". In case
you think the current name is better, I'd put a short paragraph
explaining the purpose of the whole section 3 at the beginning of this
section to provide a context for the analysis of the figures. Otherwise
I stare at the figures first without an understanding why I am doing it.

OLD:
"DHCP clients are assumed not to have routable IP addresses when they
are attempting to obtain configuration information".
NEW:
"It is assumed that DHCP clients may not have routable IP addresses when
they are attempting to obtain configuration information."

OLD:
"this relay agent, which has a routable IP address, then forwards the
DHCP requests to the DHCP server".
NEW:
"this relay agent, which has a routable IP address, then forwards the
DHCP requests to the DHCP server (directly or via other relays)".

The following statement:
"In DHCPv6 that is also possible in case where the server is configured
with a Server Unicast option and client's are able to take advantage of it."

contradicts with the assumption that clients don't have routable addres,
because they need to have a routable address to use unicast:

This is another reason why it should be said that the clients may not
have an routable IP address, rather than they don't have routable IP
address.

Since, the draft combines the use cases for DHCPv4 and DHCPv6 it is
sometimes not clear whether "DHCP server" refers to DHCPv4 server or
both DHCPv4 and DHCPv6. For example:

"In all cases, the DHCP server is able to obtain IP address that it
knows is on-link [...]".

>From the examples following the colon I understand that this is about
the DHCPv4 server. But, the use of DHCP term doesn't seem to be
consistent. In some cases the DHCP server refers to both. I'd suggest
that the "DHCP server" is used as a term for "any" server. And, DHCPv4
and DHCPv6 for respective servers. One may argue that RFC2131 defines a
DHCP protocol (not DHCPv4), but the use of terms could be cleared in the
topo-conf terminology.

Having said that, I think that section 3 would be far better readable if
it was split to 2 distinct sections. One for DHCPv4, another for DHCPv6.
Otherwise, the text jumps back and forth between the two contexts.

This paragraph sounds awkward:

"  In all cases, the DHCP server is able to obtain an IP address that it
   knows is on-link for the link to which the DHCP client is connected:
   either the DHCPv4 client's routable IPv4 address, or the relay
   agent's IPv4 address on the link to which the client is connected.
   So in every case the server is able to determine the client's point
   of attachment and select appropriate subnet- or link-specific
   configuration."

It would be better to say:

"  The DHCP server uses an IP address from the client's message which is
on the same link as the client to perform address assignment decisions
or to select subnet-specific configuration for the client. The address
that the server uses is the DHCP client's routable IP address or the
client facing address of the relay agent."

Or something similar. But the key is that the server extracts the IP
address for the purpose, and the purpose should be stated first. In the
original text is sounds like the ability to select a subnet or
link-specific configuration is a side effect of doing something else.

I'd remove the "Somewhat contrary to its name [...]". The name is the
name and it is not the intent of this draft to resolve issues with names
defined elsewhere.

I don't understand this: "In normal circumstances this is the solution
that is the easiest to maintain." In particular, I don't understand what
exact aspects of "maintenance" are the easiest here? Or, what the
maintenance is in this context?

Section 4: In the JSON example there is on-link["a"]. Shouldn't it be
on-link["A"] ?

Marcin

On 29/09/14 16:36, Bernie Volz (volz) wrote:
> Hi all,
> 
>  
> 
> This message starts the DHC working group last call to advance
> "Customizing DHCP Configuration on the Basis of Network Topology”,
> draft-ietf-dhc-topo-conf-03, document as an Informational RFC. The
> authors believe that this version is ready.
> 
>  
>

---

From: Qi Sun <[email-masked]>
Date: Tue, 14 Oct 2014 00:42:30 +0800

Dear all,

I’ve read this document and support its moving forward.

Here are some minor editorial comments:
1) Sec 2, Terminology
Should it be 'Shared subnet’ or 'Shared subnets’ ?

2) On Page 6, 
OLD:
  In all cases, the DHCP server is able to obtain an IP address that it
  knows is on-link for the link to which the DHCP client is connected: …

Could I suggest s/obtain/identify/ ? The word ‘obtain’ might confuses the reader that the DHCP server is acquiring an IP address for itself. 

Best Regards,
Qi

On Oct 7, 2014, at 11:07 AM, Bernie Volz (volz) <[email-masked]> wrote:

> On Sep 29, 2014, at 10:36 AM, Bernie Volz (volz) <[email-masked]> wrote:
> 
>> Hi all,
>>

---

From: 神明達哉 <[email-masked]>
Date: Mon, 13 Oct 2014 11:38:40 -0700

At Tue, 07 Oct 2014 16:46:27 +0200,

> Simon, Jinmei and Suresh) to double check that all your comments were

Assuming you meant this:
http://www.ietf.org/mail-archive/web/dhcwg/current/msg15442.html
I've checked if these are addressed in the 03 version (I've not
(re-)reviewed entire text of the latest version, though).

Some of these comments don't seem to be addressed or may need some
update:

- My question on this sentence seems to still remain:

   [...]  It is
   up to administrator to make sure that the interface-id is unique
   within his administrative domain.

- Regarding this text:

   In all cases, then, the DHCP server will have a link-identifying IP
   address, and in some cases it may also have a link-specific
   identifier (e.g.  Interface-Id Option or Link Address Option defined
   in Section 5 of [RFC6977]).  It should be noted that there is no
   guarantee that the link-specific identifier will be unique outside
   the scope of the link-identifying IP address.

  My question on the second sentence seems to be still open.  Pasting
  it: 'The second sentence is also not really clear to me...what does
  "outside the scope of the link-identifying IP address" mean?
  Usually "the link-identifying IP address" should be global, so there
  is basically no "outside the scope" of it in the first place.'

- Regarding the comment on Section 8, I see an additional paragraph
  has been added, seemingly for addressing my comment.  I don't have
  an objection to the text itself, but the sense of the revised text
  is slightly different from what I would have envisioned.  I propose
  the following text instead:

   [...]  When changes
   are made to the DNS server, these changes are promptly and
   automatically adopted by the DHCP server, as long as the DNS server
   is managed appropriately (see the next paragraph).  Similarly, ...

   It should be noted that even though the DHCP server may be
   configured to query the DNS resolver every time it uses configured
   names, the changes made in the DNS zone may not be visible to the
   server until the DNS cache expires.  In general, it's the
   responsibility of the DNS zone's administrator to ensure that
   existing cache does not cause a trouble when a change is made to
   the zone; it should be usually reasonable for the DHCP server to
   rely on it.  However, if this is not desired or if the management
   of the DNS zone is not very reliable, the DHCP server can be
   configured to query the authoritative DNS server directly,
   bypassing any caching DNS servers.

--
JINMEI, Tatuya