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

From: Tomek Mrugalski <[email-masked]>
Date: Fri, 09 Jan 2015 21:04:34 +0100

It took definitely more time than I had hoped, but I finally got round
to the comments. The -04 version is availalbe here:
here: https://tools.ietf.org/html/draft-ietf-dhc-topo-conf-03

On 07.10.2014 17:11, JF Tremblay wrote:
> 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.
Good point. Added the following clarification:

   If for whatever reason that is not feasible (e.g. because the relay
   agent does not have a global address or ULA [RFC4193] configured on
   the client-facing interface), the relay agent includes ...

> 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.
I reworded this section a bit, but I agree that implementation of this
feature is very implementation specific. If we wanted to extend it
seriously, it would be either very high level or would have to go
through all the details. Neither would do much good here.

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

> Also, interesting choice of wording in the IANA section… ;)
All the credit goes to our respectable AD and his absolving powers ;)

Tomek

---

From: Tomek Mrugalski <[email-masked]>
Date: Fri, 09 Jan 2015 21:07:38 +0100

> here: https://tools.ietf.org/html/draft-ietf-dhc-topo-conf-03
Ooops, I meant http://tools.ietf.org/html/draft-ietf-dhc-topo-conf-04

Apparently, tools.ietf.org needs couple more minutes after draft
submission, before the links are updated.

Tomek

---

From: Tomek Mrugalski <[email-masked]>
Date: Fri, 09 Jan 2015 21:14:08 +0100

Thanks for this review and sorry about getting it so long to address
your comments. Please see update -04 with your comments hopefully
addressed: http://tools.ietf.org/html/draft-ietf-dhc-topo-conf-04.
Comments in-line.

On 13.10.2014 13:50, Marcin Siodelski wrote:
> Section 3: The title of this section sounds ambiguous. IMO, the better
> name would be "Identifying Client's Location by DHCP servers". In case
Updated.

> 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."
Replaced.

> 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)".
Replaced.

> 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.
It is now split into initial common section followed by DHCPv4 and
DHCPv6 specific subsections. Hopefully it will be cleaner now.

> 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."
Updated as suggested.

> 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 left this particular text as is. The major purpose of this draft is to
comment on and explain existing mechanisms, so I think the comment is
somewhat appropriate. I recall that we had a brief discussion in the
3315bis context where we wondered if link-address field should be
renamed. We decided to leave it as it is. So this name may be a bit
counter-intuitive.

> 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?
Added clarification what type of maintenance was meant. Using existing
addresses is easier to maintain than introducing a new type of
identifiers, assigning them, making sure they are unique, maintain a
list of those identifiers etc.

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

Thanks for your careful review.
Tomek

---

From: Tomek Mrugalski <[email-masked]>
Date: Fri, 09 Jan 2015 21:22:45 +0100

Apologies for such a late response and for not addressing your previous
comments. Hopefully I did less pathetic job this time. Please see
updated http://tools.ietf.org/html/draft-ietf-dhc-topo-conf-04.

On 13.10.2014 20:38, 神明達哉 wrote:
> 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.
That was a valid concern. While the interface-id may be used for link
selection if it's unique in an administrative domain, there's no
guarantee that it will be. The text now says:

   If the interface-id is unique within an
   administrative domain, the interface-id value may be used to select
   appropriate subnet.  As there is no guarantee for the uniqueness
   ([RFC3315] only mandates the interface-id to be unique within a
   single relay agent context), it is up to the administrator to check
   whether the relay agents deployed use unique interface-id values.  If
   they aren't, Interface-id cannot be used to determine client's point
   of attachment.

> - 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.'
Maybe scope is a poor choice of words here, but I don't know how to find
a better way to explain it. What we (I think Ted is the original author
of that part) wanted to say here is that the link-specific identifier on
its own is not that useful, only a tuple of IP address + link-specific
identifier is useful. Added the following clarification:

   For example, link-specific indentifier of
   "eth0" for a relay agent with IPv4 address 192.0.2.1 means something
   different than "eth0" for a relay agent with address 192.0.2.123.

Hopefully it will be sufficient. If it isn't, it would be great if you
could offer a better text.

> - 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.
Updated the text as suggested.

Thanks a lot for your comments.

Tomek

---

From: 神明達哉 <[email-masked]>
Date: Mon, 12 Jan 2015 10:27:04 -0800

At Fri, 09 Jan 2015 21:22:45 +0100,

>    they aren't, Interface-id cannot be used to determine client's point

(Note: below, I only talk about a relay agent that forwards DHCPv6
message from clients, not another relay agent, for simplicity).

First off, just wondering: where in RFC3315 does it "mandate the
interface-id to be unique within a single relay agent context"?
Although that's a valid understanding (and it in fact matches mine) of
what interface-id's should be by definition, I don't see any explicit
requirement in RFC3315 about that.

Secondly, I suspect it's super rare that interface-id's are unique
among all relay agents in a specific DHCPv6 service domain, so the
text still looks quite awkward to me.

Thirdly, on re-reading relevant documents, I now wonder in which case
a relay agent ends up (necessarily) including the interface-id option
in the first place.  RFC 3315 Section 20.1.1 states:

   If the relay agent received the message to be relayed from a client,
   the relay agent places a global or site-scoped address with a prefix
   assigned to the link on which the client should be assigned an
   address in the link-address field. [...]

   If the relay agent cannot use the address in the link-address field
   to identify the interface through which the response to the client
   will be relayed, the relay agent MUST include an Interface-id option
   (see section 22.18) in the Relay-forward message.

Now that site-local unicast addresses have been deprecated, this means
the relay agent always specifies a global address for the link-address
field (although there's no RFC2119 keyword here).  In which case could
the relay agent not "use the address to identify the interface
through which the response to the client will be relayed", then?  I
can imagine one scenario in the era of RFC3315 (although I don't know
that was the original intent of the RFC): the relay agent is located
at a site-border, receiving messages from DHCPv 6 clients from
different sites, and some links to different sites are associated with
the same site-local prefix (the relay agent could still disambiguate
the interface using some node-local "interface-id").  But, with the
deprecation of unicast site-local addresses we don't have to think
about such cases anymore.

Depending on the answer to these points, I may be able to propose text
that would address my concern.  Right now, though, I feel I'm now even
more confused.

> could offer a better text.

Sorry, but this is even more confusing to me...I don't even understand
why it now talks about IPv4 addresses.

This is also related to the previous point, btw: with the deprecation
of unicast site-local addresses, the link-identifying IP (which I
interpret means the innermost link-address field of the relay forward
message) should be always global, and should always be unique all over
the world, no?

BTW, the proposed new text seems to have some editorial issues:
- s/indentifier/identifier/
- I guess "there" should have been removed from: "It should be noted
  that there the link-specific identifier is unique..."

Finally: one other thing I noticed as I write this response: in the
same Section (3.2):

   For completeless, we also mention an uncommon, but valid case, where
   relay agents set link-local address in the link-address field in
   relayed Relay-forward messages.

I don't think this is a valid case, since RFC 3315 clearly states the
link-address field is a global or (now-deprecated) site-local address
as noted above (again, even though there's no RFC2119 keyword here).

--
JINMEI, Tatuya