Re: [Int-dir] [dhcwg] Intdir last call review of draft-ietf-dhc-slap-quadrant-08

[CARLOS JESUS BERNARDOS CANO <[e-mail]>]

Hi,

Thanks, please see inline below.

On Fri, May 29, 2020 at 6:49 PM 神明達哉 <[e-mail]> wrote:

> At Wed, 27 May 2020 18:55:57 +0200,
> CARLOS JESUS BERNARDOS CANO <[e-mail]> wrote:
>
> > > Specific comments:
> > >
> > > - Section 4.1-3
> > >        [...]  The client SHOULD NOT pick a server that does not
> > >        advertise an address in the requested quadrant.
> > >
> > > Does this mean if a client follows this "SHOULD NOT" and receives
> > > Advertise messages from servers that don't understand the new QUAD
> > > option, then the client can't choose any server?  If so, is it okay?
> >
> > [Carlos] Yes, in that case the expected behaviour would be that the
> client
> > does not choose any server. This is basically the same that happens with
> > other DHCP extensions. In any case, the text you referred to above was
> more
> > to describe what the client should do if the server supports the QUAD
> > option, but still does not have addresses available from the selected
> > quadrant.
>
> I understand that (what this text is about).  My question was about
> the compatibility with legacy servers and newer clients.  I don't know
> of other similar cases in DHCP(v6) extensions, but in any case if
> breaking the compatibility is the intent, I don't oppose that.  I just
> wanted to make sure if it's intentional.
>
> > > - Section 4.1:
> > >    5.  When the assigned addresses are about to expire, the client
> sends
> > >        a Renew message.  It includes the preferred SLAP quadrant(s) in
> > >        the new QUAD IA_LL-option, so in case the server is unable to
> > >        extend the lifetime on the existing address(es), the preferred
> > >        quadrants are known for the allocation of any "new" addresses.
> > >
> > > It's not clear to me what 'the preferred quadrants are known for the
> > > allocation of any "new" addresses' means.  Does this mean the server
> > > will assign a new address from the specified quadrant(s) in response
> > > to the Renew in this situation?
> >
> > [Carlos] Yes. If the currently assigned addresses cannot be renewed, then
> > the server will try to allocate different (that's what "new" means)
> > addresses from the same quadrant. We have added "different" to the text
> in
> > version -09 to make this clearer.
>
> Hmm, isn't it different from what the server would do with Renew for
> other types of IAs?  (Assuming that's correct) being different itself
> isn't necessarily wrong, but in that case I'd like to see an
> explanation on why it differs.
>

[Carlos] Not sure if I got your point. Do you refer to adding an
explanation of why the server might not be able to renew the addresses that
the client is using? Because this might be for different operational
reasons (like it might happen with IP addresses for example).


> BTW, "what 'new' means" isn't an issue for me, so the change in 09
> doesn't affect my point.
>
> > > - Section 4.2-3
> > > The preference between client's supplied QUAD and relay supplied QUAD
> > > (or whether it matters) isn't clear to me.   What if these are
> > > inconsistent?  Perhaps this paragraph at the end of Section 4.2
> > > answers the question?
> > >
> > >    The server SHOULD implement a configuration parameter to deal
> > >    with the case where the client's DHCP message contains an instance
> of
> > >    OPTION_SLAP_QUAD, and the relay adds a second instance in its relay-
> > >    forward message.  [...]
> > >
> > > If so, it might be more reader friendly if 4.2-3 gives a forward
> > > reference to this consideration.  Also, this paragraph seems to
> > > suggest the server may (only) process the relay's instance of the QUAD
> > > option.  If so, and it's incompatible with the client's option, then I
> > > guess the same question as Section 4.1-3 applies here.
> >
> > [Carlos] That's a good point. When we wrote this we thought that the
> > sentence "Depending on the server's policy, the instance(s) of the option
> > to process is selected." in 4.2-3 would be sufficient as a reference for
> > what comes at the end of Section 4.2 (which is indeed the answer to your
> > point). I think adding a more explicit reference would make the text
> > unnecessary long. What do you think?
>
> I don't think it "unnecessarily long" to add a short forward reference
> like "see also at the end of this section" after "Depending on ...is
> selected", but these are all about readability, which is generally
> subjective.  If you believe the current text is the best I don't
> oppose.
>

[Carlos] OK, I've added your suggested text in -10.


>
> > > - Section 5.1
> > >
> > >    [...]  Note that a quadrant - preference tuple is
> > >    used in this option (instead of using a list of quadrants ordered by
> > >    preference) to support the case whereby a client really has no
> > >    preference between two or three quadrants, leaving the decision to
> > >    the server.
> > >
> > > What does "a quadrant - preference tuple is used in this option" mean?
> > > From the context I guess it tries to talk about using the same
> > > preference for multiple quadrants, but the actual text doesn't really
> > > read that way to me...
> >
> > [Carlos] It means that the option includes pairs (tuples) of quadrant-n &
> > pref-n. Would it be clearer if we use "pair" instead of tuple?
>
> Ah, I now see where my confusion comes from.  On my first read I
> misunderstood that this entire text talks about some actual protocol
> behavior, but now I see the text after "Note that..." explains your
> design choice (correct?).  Now that I (hopefully) understand it's
> difficult to suggest how to prevent the same kind of confusion, but
> I'd perhaps say, e.g.
>
>    If the same preference value is used for more than one quadrant, the
>    server MAY select which quadrant should be preferred (if the server
>    can assign addresses from all or some of the quadrants with the same
>    assigned preference).  Note that this is not a simple list of
>    quadrants ordered by preference without no preference value but a
>    list of quadrants with explicit preference values.  This way it can
>    support the case whereby a client really has no preference between
>    two or three quadrants, leaving the decision to the server.
>
> [Carlos] Very good, thanks! I've adopted your proposed text.


> > > - Section 5.1
> > >
> > >    [...]  If the server can provide an assignment from one of the
> > >    specified quadrants, it SHOULD proceed with the assignment.  If the
> > >    server cannot provide an assignment from one of the specified
> > >    quadrant-n fields, it MUST NOT assign any addresses and return a
> > >    status of NoQuadAvail (IANA-2) in the IA_LL Option.
> > >
> > > The first and second sentece seem to contradict each other.  If, for
> > > example, two quadrants Q1 and Q2 are specified and the server can only
> > > provide an assignment for Q1, what should it do?  The first sentence
> > > seems to say the server should proceed with the assignemtn for Q1; the
> > > second sentence seems to say the server MUST NOT assign any address
> > > and simply return NoQuadAvail.
> > >
> > > BTW, the second sentence also seems to contradict Section 4.1?  4.1-2
> > > states:
> > >
> > >        [...] If
> > >        the client specified more than one SLAP quadrant, the server
> MUST
> > >        only return a NoQuadAvail status code if no address pool(s)
> > >        configured at the server match any of the specified SLAP
> > >        quadrants.
> > >
> > > [Carlos] Maybe is an English issue here (note that I'm not a native
> > speaker). What we mean is that if the server does not have at least
> > addresses from one of the specified quadrants, it must not assign any. So
> > if Q1 and Q2 are requested, and the server has only addresses from Q1,
> this
> > is fine and it should proceed with the assignment for Q1. Only if the
> > server does not have addresses from neither Q1 or Q2 it should return
> > NoQuadAvail.
>
> Okay, in that case I'd change
>
> > >    server cannot provide an assignment from one of the specified
>
> to
>
> > >    server cannot provide an assignment from any of the specified
>
> i.e., "one" to "any".  At least to me this will make the two sentences
> clearly consistent.
>

[Carlos] OK, done. Thanks!

Thanks a lot!

Carlos


>
> BTW I'm not a native English speaker either, so it's quite possible
> that it's due to my poor reading of English text:-)
>
> --
> JINMEI, Tatuya
>