Re: [dhcwg] Barry Leiba's No Objection on draft-ietf-dhc-slap-quadrant-09: (with COMMENT)

CARLOS JESUS BERNARDOS CANO <cjbc@it.uc3m.es> Mon, 03 August 2020 16:25 UTC

Return-Path: <cjbc@it.uc3m.es>
X-Original-To: dhcwg@ietfa.amsl.com
Delivered-To: dhcwg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 56C4A3A0F33 for <dhcwg@ietfa.amsl.com>; Mon, 3 Aug 2020 09:25:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.098
X-Spam-Level:
X-Spam-Status: No, score=-0.098 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=it.uc3m.es
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fBhVlubo4RiF for <dhcwg@ietfa.amsl.com>; Mon, 3 Aug 2020 09:25:46 -0700 (PDT)
Received: from mail-io1-xd2a.google.com (mail-io1-xd2a.google.com [IPv6:2607:f8b0:4864:20::d2a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4C3353A0F36 for <dhcwg@ietf.org>; Mon, 3 Aug 2020 09:25:46 -0700 (PDT)
Received: by mail-io1-xd2a.google.com with SMTP id j8so26778295ioe.9 for <dhcwg@ietf.org>; Mon, 03 Aug 2020 09:25:46 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=it.uc3m.es; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=sn4VqcbAfTAkYAzpvH6q0v0c5HWGD6wc/MhVJcjXG5c=; b=n4aVeATTN59N+5bngxpT9xD/HfAWZR1NrNNzAA/yVnBElAB5fN237sY+tijRYub4hq btqTgAs56ha+nlTzVqYQNEuJkHLF6CmEgVnzU76cvsvkD7ENsPxHu1L8rLQGzbN8Aix3 cbJqW6UmSCiOyuBZEjEZ5UdLJ/8u8+VeFQ139tzpN74wSNRspvEMvBSSzeIaQ6/7bf6V wNdFD7lFqVmcdc6EnRQQjmF118ps8KL+D2Eh5vtPCTnxcz1KidDpMu+XVcHkjLowsqlz sTfTBw8wobtWgrpaxVHMhGzm+inzrrXEYarb14kzgeUS4GPtlmRbt+Owwjp/Y1QGkRet XXFw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=sn4VqcbAfTAkYAzpvH6q0v0c5HWGD6wc/MhVJcjXG5c=; b=goEzZKKztgPg1wbdJWwwXa2TAY8jCawFInb/sfR//x2zM+7kl5yEPbIcBTU+lsFkaL vvEyjJSYyaPYxoTh1CtQtX52RbqAj04XqP7fqPnueNdNBiD7yb85Y0RXdAQSak6Xu9/e zoQIG6g9Ug1igoEThzt9B1xCtLH95mPFcWnNff2bXPVaXLImKf6fcCbAVCn/KB8hY9sj qs3cXTm3tooSEjKmZxO6JMhWUGhBDAsJWhgtOt8RkQHYHJd78nyP6vdC7iHPOa2arDXh adhjOGu+O7GDDAr/ClzEOUROvV6yG8kOYWMjS23ufF1Y6cctaOMW5FGYRYZnC289efcR Db0A==
X-Gm-Message-State: AOAM531/C3sbAKhnB73eFqy5bnZ6/RfqwU1D3E7iGQTuPDEcjps2hWV0 o3GfWb8yEXE6UCsDj+b4t0T/yBc4XAHdiuqeKY4VuQ==
X-Google-Smtp-Source: ABdhPJyOYQjnWzsfIYVW/Ob5AIU38CHPkxI086xfBP41JwFs/k9UE830ssIg1PNgRzFdrhCs/cwxyvr5z3f9frS/CLU=
X-Received: by 2002:a6b:5c17:: with SMTP id z23mr640662ioh.67.1596471945165; Mon, 03 Aug 2020 09:25:45 -0700 (PDT)
MIME-Version: 1.0
References: <159166707503.4308.11011951864784667729@ietfa.amsl.com> <CALypLp_J_k3qFMaUteQvq6coEY-ZFwkbD1YB82W0GEDSKpT4VQ@mail.gmail.com> <CALaySJJ8TXBLy6iJZpxiN-LuVFejmJh4B0cjtPotwhwBFOWiBQ@mail.gmail.com>
In-Reply-To: <CALaySJJ8TXBLy6iJZpxiN-LuVFejmJh4B0cjtPotwhwBFOWiBQ@mail.gmail.com>
From: CARLOS JESUS BERNARDOS CANO <cjbc@it.uc3m.es>
Date: Mon, 3 Aug 2020 18:25:28 +0200
Message-ID: <CALypLp8wczjvJq+8Akxg1mRyzeDE2HO3Bzuf6Z9-6V2OrgHhtQ@mail.gmail.com>
To: Barry Leiba <barryleiba@computer.org>
Cc: The IESG <iesg@ietf.org>, draft-ietf-dhc-slap-quadrant@ietf.org, dhc-chairs@ietf.org, dhcwg <dhcwg@ietf.org>, Tomek Mrugalski <tomasz.mrugalski@gmail.com>, Ian Farrer <ianfarrer@gmx.com>
Content-Type: multipart/alternative; boundary="0000000000002faa7605abfb97ac"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dhcwg/gIxOlMk-BsMMA3DD3hYBVkrH7m8>
Subject: Re: [dhcwg] Barry Leiba's No Objection on draft-ietf-dhc-slap-quadrant-09: (with COMMENT)
X-BeenThere: dhcwg@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: <dhcwg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dhcwg>, <mailto:dhcwg-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dhcwg/>
List-Post: <mailto:dhcwg@ietf.org>
List-Help: <mailto:dhcwg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dhcwg>, <mailto:dhcwg-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 03 Aug 2020 16:25:48 -0000

Hi Barry,

Thanks! Please see inline below.

On Fri, Jul 31, 2020 at 9:42 PM Barry Leiba <barryleiba@computer.org> wrote:

> Thanks for the reply, Carlos.  Just responding to the two items for
> which there are questions -- and keep in mind that my comments are
> suggestions, and that you should do as you think best.
>
> >>    o  Quadrant "Reserved for future use" where MAC addresses may be
> >>
> >> Nit: remove “where”.
> >
> > [Carlos] Why should I remove it? Current text reads:
> >
> >    o  SLAP Quadrant 10 is "Reserved for future use" where MAC addresses
> >       may be assigned using new methods yet to be defined, or until then
> >       by an administrator as in the AAI quadrant.  For 48-bit MAC
> >       addresses, 44 bits would be available.
>
> If you've changed the list text this comment might not apply any more,
> but I suggested removing "where" because it makes that item different
> from all the others in the list.  In -09, the list looks like this:
>
>    o  Quadrant "Extended Local Identifier" (ELI) MAC addresses are
>       assigned based on a Company ID (CID)
>
>    o  Quadrant "Standard Assigned Identifier" (SAI) MAC addresses are
>       assigned based on a protocol specified in an IEEE 802 standard.
>
>    o  Quadrant "Administratively Assigned Identifier" (AAI) MAC
>       addresses are assigned locally by an administrator.
>
>    o  Quadrant "Reserved for future use" where MAC addresses may be
>       assigned using new methods yet to be defined
>
> Why does the last one have "where", and the first three don't?  The
> nit I noted was just the lack of parallelism, that's all.
>

[Carlos] Current text (in -10 to be submitted) is the following:

-8-<-
   o  In SLAP Quadrant 01, "Extended Local Identifier" (ELI) MAC
      addresses are assigned based on a 24-bit Company ID (CID),
      assigned by the IEEE Registration Authority (RA).  The remaining
      bits are specified as an extension by the CID assignee or by a
      protocol designated by the CID assignee.

   o  In SLAP Quadrant 11, "Standard Assigned Identifier" (SAI) MAC
      addresses are assigned based on a protocol specified in an IEEE
      802 standard.  For 48-bit MAC addresses, 44 bits are available.
      Multiple protocols for assigning SAIs may be specified in IEEE
      standards.  Coexistence of multiple protocols may be supported by
      limiting the subspace available for assignment by each protocol.

   o  In SLAP Quadrant 00, "Administratively Assigned Identifier" (AAI)
      MAC addresses are assigned locally by an administrator.  Multicast
      IPv6 packets use a destination address starting in 33-33, so AAI
      addresses in that range should not be assigned.  For 48-bit MAC
      addresses, 44 bits are available.

   o  SLAP Quadrant 10 is "Reserved for future use" where MAC addresses
      may be assigned using new methods yet to be defined, or until then
      by an administrator as in the AAI quadrant.  For 48-bit MAC
      addresses, 44 bits would be available.
-8-<-

The last one is a bit different because it is the quadrant that is reserved
for future use.


> >> — Section 4.1 —
> >>
> >>       The client SHOULD NOT pick a server that does not
> >>        advertise an address in the requested quadrant.
> >>
> >> This SHOULD NOT doesn’t make sense to me.  Why would it?  What would be
> an
> >> informed reason to pick one that doesn’t have what it wants?  Is there
> a reason
> >> not to just say, “The client will pick a server that advertises an
> address in
> >> the quadrant the client requested,” without using BCP 14 key words?
> >>
> > [Carlos] We wrote in that way to leave freedom for cases in which maybe
> there are no
> > servers that have what the client wants (or better, prefers) and still
> allow the client to
> > get an address allocation from a server.
>
> It might be good, then, to explain that briefly: the text that's there
> simply says what I quote above, with no explanation, and says nothing
> about what the client might want or prefer.  So when I read it, I say
> to myself, "If I ask for an address in a specific quadrant, why would
> I pick a server that doesn't have one?"  Maybe it's just as simple as,
> "The client will pick a server that advertises an address in the
> quadrant the client requested, unless no server advertises one."  Or
> maybe the "SHOULD NOT" is fine with a brief explanation.  Or maybe
> readers will just understand this, and I'm blowing smoke: as I said,
> do as you think best.
>

[Carlos] OK, I see your point. I still think I'm going to keep the current
text.

Thanks a lot!

Carlos


>
> Barry
>