From nobody Tue Jun 2 08:41:28 2020 Return-Path: X-Original-To: int-dir@ietfa.amsl.com Delivered-To: int-dir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ADA853A0C48 for ; Tue, 2 Jun 2020 08:41:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 o3aNrx5k6Zwe for ; Tue, 2 Jun 2020 08:41:05 -0700 (PDT) Received: from mail-io1-xd35.google.com (mail-io1-xd35.google.com [IPv6:2607:f8b0:4864:20::d35]) (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 C88103A0C28 for ; Tue, 2 Jun 2020 08:41:04 -0700 (PDT) Received: by mail-io1-xd35.google.com with SMTP id s18so11329429ioe.2 for ; Tue, 02 Jun 2020 08:41:04 -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=F4HJ15FjDmNJC3njQv1SRbAIdzQwYlaIv31aBos8n9M=; b=VsYh3W61sFC7L5L+fYLGK0Y2d5wL/k30hxF99HLuW2zLKKtxqM0skvgLH2t7deNTaT GO/6CRzH5WPf90YqlbxD06a+2RMYqqD5Dmev2NCUl32io6dl+GbLlb+B7iTUic6ikpfY RqI1K6iDN/AUWXTRV+xXRLYxt50COlmcqHwzJ4dK4TifV1YBc06PIHXK41cse4BmUXJ1 xqsqHI7WoGhz1o8F7skgHDhaTuZlqfc+ETwAY94dpzMNi31dmSfr+O3YBV1Ns5kw9D/w v8gKQz1SeUiJ2tvA1P25e/xSKpbWW/Pbh+eMtSy8mRSriRv4q1/k5NGigJ0s5pB1oDf2 SXZw== 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=F4HJ15FjDmNJC3njQv1SRbAIdzQwYlaIv31aBos8n9M=; b=MtGlGeT07ZY8H9me566abiA3WGZ+N9N1Y6W3n/fm+57CX65IZQlbgrJpTqi1mP6X/G 8SbOtphFiYe1V1CiRpe5UzWFU6B66AWNpIEnOiU1QHv2H9nb2QrpE5wwYsl6cj3eYOxO jidReWf15ngvpZNTgEoR0rvDyEm3A5yMB3QlOB44dXsEyabaAAksZLvDmWfdWNKhXMUI TKJl4nYz5w8ZFneOnc4urLEM/+6sG0tg++FVp/SDFBzf/rJleXA/U5EMcxJJuJKHOoQp VbiqfOOhZQd13IkXRv02/MTJrunSjxvQNsegIYVm//eXWjczp6e8mwJ/hIe6bhNInVH/ Qlwg== X-Gm-Message-State: AOAM533LnJGTxvuAnLwyC7tVBTjlbhdr9uPsP7mf4xLr92Lvv6uW6LHX 5vMQKhrzSMfCjed9etW1AYMYV/l/BysulelPVp70tQ== X-Google-Smtp-Source: ABdhPJz81VX9Ax169SUgz8LDiLaSv72XjaXCbjP508LX+LSRiPEFSV57RysejEOJIxmc8NxWYokoxn9S+7husXAHUKU= X-Received: by 2002:a6b:5a07:: with SMTP id o7mr19088iob.67.1591112463696; Tue, 02 Jun 2020 08:41:03 -0700 (PDT) MIME-Version: 1.0 References: <158983448603.3400.6838657620034200956@ietfa.amsl.com> In-Reply-To: From: CARLOS JESUS BERNARDOS CANO Date: Tue, 2 Jun 2020 17:40:47 +0200 Message-ID: To: =?UTF-8?B?56We5piO6YGU5ZOJ?= Cc: dhcwg , last-call@ietf.org, draft-ietf-dhc-slap-quadrant.all@ietf.org, "" Content-Type: multipart/alternative; boundary="000000000000326e4405a71bbd80" Archived-At: Subject: Re: [Int-dir] [dhcwg] Intdir last call review of draft-ietf-dhc-slap-quadrant-08 X-BeenThere: int-dir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This list is for discussion between the members of the Internet Area directorate." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Jun 2020 15:41:18 -0000 --000000000000326e4405a71bbd80 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi, Thanks, please see inline below. On Fri, May 29, 2020 at 6:49 PM =E7=A5=9E=E6=98=8E=E9=81=94=E5=93=89 wrote: > At Wed, 27 May 2020 18:55:57 +0200, > CARLOS JESUS BERNARDOS CANO 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 wit= h > > 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) i= n > > > 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, th= en > > 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 rela= y- > > > 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 QUA= D > > > 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 opti= on > > to process is selected." in 4.2-3 would be sufficient as a reference fo= r > > what comes at the end of Section 4.2 (which is indeed the answer to you= r > > 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 th= e > > > 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 onl= y > > > provide an assignment for Q1, what should it do? The first sentence > > > seems to say the server should proceed with the assignemtn for Q1; th= e > > > 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 > --000000000000326e4405a71bbd80 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi,

Thanks, please see= inline below.

On Fri, May 29, 2020 at 6:49 PM =E7=A5=9E=E6=98=8E=E9= =81=94=E5=93=89 <jinmei@wide.ad.jp<= /a>> wrote:
A= t Wed, 27 May 2020 18:55:57 +0200,
CARLOS JESUS BERNARDOS CANO <cjbc@it.uc3m.es> wrote:

> > Specific comments:
> >
> > - Section 4.1-3
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 [...]=C2=A0 The client SHOULD NOT pick= a server that does not
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 advertise an address in the requested = quadrant.
> >
> > Does this mean if a client follows this "SHOULD NOT" an= d receives
> > Advertise messages from servers that don't understand the new= QUAD
> > option, then the client can't choose any server?=C2=A0 If so,= is it okay?
>
> [Carlos] Yes, in that case the expected behaviour would be that the cl= ient
> does not choose any server. This is basically the same that happens wi= th
> 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<= br> > option, but still does not have addresses available from the selected<= br> > quadrant.

I understand that (what this text is about).=C2=A0 My question was about the compatibility with legacy servers and newer clients.=C2=A0 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.=C2=A0 I = just
wanted to make sure if it's intentional.

> > - Section 4.1:
> >=C2=A0 =C2=A0 5.=C2=A0 When the assigned addresses are about to ex= pire, the client sends
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 a Renew message.=C2=A0 It includes the= preferred SLAP quadrant(s) in
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 the new QUAD IA_LL-option, so in case = the server is unable to
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 extend the lifetime on the existing ad= dress(es), the preferred
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 quadrants are known for the allocation= of any "new" addresses.
> >
> > It's not clear to me what 'the preferred quadrants are kn= own for the
> > allocation of any "new" addresses' means.=C2=A0 Doe= s this mean the server
> > will assign a new address from the specified quadrant(s) in respo= nse
> > to the Renew in this situation?
>
> [Carlos] Yes. If the currently assigned addresses cannot be renewed, t= hen
> the server will try to allocate different (that's what "new&q= uot; 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?=C2=A0 (Assuming that's correct) being different its= elf
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 usi= ng? 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 suppl= ied QUAD
> > (or whether it matters) isn't clear to me.=C2=A0 =C2=A0What i= f these are
> > inconsistent?=C2=A0 Perhaps this paragraph at the end of Section = 4.2
> > answers the question?
> >
> >=C2=A0 =C2=A0 The server SHOULD implement a configuration paramete= r to deal
> >=C2=A0 =C2=A0 with the case where the client's DHCP message co= ntains an instance of
> >=C2=A0 =C2=A0 OPTION_SLAP_QUAD, and the relay adds a second instan= ce in its relay-
> >=C2=A0 =C2=A0 forward message.=C2=A0 [...]
> >
> > If so, it might be more reader friendly if 4.2-3 gives a forward<= br> > > reference to this consideration.=C2=A0 Also, this paragraph seems= to
> > suggest the server may (only) process the relay's instance of= the QUAD
> > option.=C2=A0 If so, and it's incompatible with the client= 9;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 t= he
> sentence "Depending on the server's policy, the instance(s) o= f the option
> to process is selected." in 4.2-3 would be sufficient as a refere= nce for
> what comes at the end of Section 4.2 (which is indeed the answer to yo= ur
> 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.=C2=A0 If you believe the current text is the best I don't oppose.

[Carlos] OK, I've added you= r suggested text in -10.
=C2=A0

> > - Section 5.1
> >
> >=C2=A0 =C2=A0 [...]=C2=A0 Note that a quadrant - preference tuple = is
> >=C2=A0 =C2=A0 used in this option (instead of using a list of quad= rants ordered by
> >=C2=A0 =C2=A0 preference) to support the case whereby a client rea= lly has no
> >=C2=A0 =C2=A0 preference between two or three quadrants, leaving t= he decision to
> >=C2=A0 =C2=A0 the server.
> >
> > What does "a quadrant - preference tuple is used in this opt= ion" 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 tupl= e?

Ah, I now see where my confusion comes from.=C2=A0 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 yo= ur
design choice (correct?).=C2=A0 Now that I (hopefully) understand it's<= br> difficult to suggest how to prevent the same kind of confusion, but
I'd perhaps say, e.g.

=C2=A0 =C2=A0If the same preference value is used for more than one quadran= t, the
=C2=A0 =C2=A0server MAY select which quadrant should be preferred (if the s= erver
=C2=A0 =C2=A0can assign addresses from all or some of the quadrants with th= e same
=C2=A0 =C2=A0assigned preference).=C2=A0 Note that this is not a simple lis= t of
=C2=A0 =C2=A0quadrants ordered by preference without no preference value bu= t a
=C2=A0 =C2=A0list of quadrants with explicit preference values.=C2=A0 This = way it can
=C2=A0 =C2=A0support the case whereby a client really has no preference bet= ween
=C2=A0 =C2=A0two or three quadrants, leaving the decision to the server.
[Carlos] Very good, thanks! I've adopted your pro= posed text.
=C2=A0
> > - Section 5.1
> >
> >=C2=A0 =C2=A0 [...]=C2=A0 If the server can provide an assignment = from one of the
> >=C2=A0 =C2=A0 specified quadrants, it SHOULD proceed with the assi= gnment.=C2=A0 If the
> >=C2=A0 =C2=A0 server cannot provide an assignment from one of the = specified
> >=C2=A0 =C2=A0 quadrant-n fields, it MUST NOT assign any addresses = and return a
> >=C2=A0 =C2=A0 status of NoQuadAvail (IANA-2) in the IA_LL Option.<= br> > >
> > The first and second sentece seem to contradict each other.=C2=A0= If, for
> > example, two quadrants Q1 and Q2 are specified and the server can= only
> > provide an assignment for Q1, what should it do?=C2=A0 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 addre= ss
> > and simply return NoQuadAvail.
> >
> > BTW, the second sentence also seems to contradict Section 4.1?=C2= =A0 4.1-2
> > states:
> >
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 [...] If
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 the client specified more than one SLA= P quadrant, the server MUST
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 only return a NoQuadAvail status code = if no address pool(s)
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 configured at the server match any of = the specified SLAP
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 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<= br> > server does not have addresses from neither Q1 or Q2 it should return<= br> > NoQuadAvail.

Okay, in that case I'd change

> >=C2=A0 =C2=A0 server cannot provide an assignment from one of the = specified

to

> >=C2=A0 =C2=A0 server cannot provide an assignment from any of the = specified

i.e., "one" to "any".=C2=A0 At least to me this will ma= ke the two sentences
clearly consistent.

[Carlos] OK, done. = Thanks!

Thanks a lot!

Car= los
=C2=A0

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
--000000000000326e4405a71bbd80-- From nobody Tue Jun 2 11:04:54 2020 Return-Path: X-Original-To: int-dir@ietfa.amsl.com Delivered-To: int-dir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6A47B3A0E16; Tue, 2 Jun 2020 11:04:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.401 X-Spam-Level: X-Spam-Status: No, score=-1.401 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.249, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.249, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no 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 U34LddXKStQk; Tue, 2 Jun 2020 11:04:41 -0700 (PDT) Received: from mail-wr1-f47.google.com (mail-wr1-f47.google.com [209.85.221.47]) (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 636093A0EA6; Tue, 2 Jun 2020 11:04:38 -0700 (PDT) Received: by mail-wr1-f47.google.com with SMTP id h5so4326461wrc.7; Tue, 02 Jun 2020 11:04:38 -0700 (PDT) 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=xXhgF/BeeFMaMvT2F2aUVL2rBvW8rhtJ4kv2pSw6uhE=; b=WwnULVEuNS9WW/1Fzr4CyTLLteNAxUKggsy/cgxpiBTv5XiDfbjmIIVHqjfAIunKpt jISRAhjW29T2V3dQXgLoCjitZF/AfhvEUHtlh8OsAqvCMivGj2IPxwtfRbID+cd+y4fh s66vdjHMjNhPZfPM2JHLdp9ZwPJyhm+MsosrFXHs63xFLBC0oZsLuGSxAfUxpC+P9Uqe 84SCgL+WnEuR/L3oYzZ7rGRzAOSRAm1FbP45Xld/NEQiU6NaaasGm8QrL3IKZ7GIL2dq UKmFw1x9ZcOX9DBS694krFinD4Dne8fycxEkXqV+kG7Ys8q8DGf9oELsRwzOJT/aTC5x 6+WQ== X-Gm-Message-State: AOAM5311VADBL3nj6CKjhHqgmcJZS0kLfDwMR8p9xnf8Vr4t8/s3uWA3 vyKviYmBS+PD+qWrVWyzoLUjAYcJs8ojBiauVUQ= X-Google-Smtp-Source: ABdhPJxqIsWovvGZSs0l/MxpRDcIZ7/YJLtbZeAI//UvuHke837hWo2uoXllkWLUPvTr9Vgnv9iJcbM8ilmEAEKYGDU= X-Received: by 2002:adf:e749:: with SMTP id c9mr29719446wrn.25.1591121076756; Tue, 02 Jun 2020 11:04:36 -0700 (PDT) MIME-Version: 1.0 References: <158983448603.3400.6838657620034200956@ietfa.amsl.com> In-Reply-To: From: =?UTF-8?B?56We5piO6YGU5ZOJ?= Date: Tue, 2 Jun 2020 11:04:24 -0700 Message-ID: To: CARLOS JESUS BERNARDOS CANO Cc: dhcwg , "" , draft-ietf-dhc-slap-quadrant.all@ietf.org, last-call@ietf.org Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [Int-dir] [dhcwg] Intdir last call review of draft-ietf-dhc-slap-quadrant-08 X-BeenThere: int-dir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This list is for discussion between the members of the Internet Area directorate." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Jun 2020 18:04:45 -0000 At Tue, 2 Jun 2020 17:40:47 +0200, CARLOS JESUS BERNARDOS CANO wrote: > > > > 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). I thought the server doesn't make a new assignment for IA_NA or IA_PD when the server finds the lifetimes of the currently (IPv6) address or prefix cannot be extended. And I thought this specification somehow deliberately differs from these cases. But on re-reading RFC8415 I've noticed this: The server may choose to change the list of addresses or delegated prefixes and the lifetimes in IAs that are returned to the client. It doesn't seem to discuss the implication of being unable to extend the lifetimes regarding this behavior, but I now see that assigning a different resource (IPv6 address or prefix, or in this draft's case, L2 address) in response to Renew. So please simply ignore this comment. -- JINMEI, Tatuya From nobody Tue Jun 2 11:13:07 2020 Return-Path: X-Original-To: int-dir@ietfa.amsl.com Delivered-To: int-dir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9F6783A0E58 for ; Tue, 2 Jun 2020 11:13:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 d64GZDGPJoox for ; Tue, 2 Jun 2020 11:13:00 -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 9C5753A0E6F for ; Tue, 2 Jun 2020 11:13:00 -0700 (PDT) Received: by mail-io1-xd2a.google.com with SMTP id d5so11821859ios.9 for ; Tue, 02 Jun 2020 11:13:00 -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=zEPNGRivVbds9plHiKXTNoXqZ1vyUAijkxR3WfY4Bwk=; b=RbYVk35LLs4LrnY4ANKQ7ZW2KDDU1+gMXToXIpOJnKAIrzJrpU6IPXv0b2VE/gvDKH QKRb5jo0b8Uoe4bqwWQNtNR379DRJoHmtH/IAdx0UNdM+pUI/YtRKrdQyMCe2TrFgmLn u0oTOAIyVAOLUhYw67kY98bOwgLY9hxxEsimM3q8u1CF6MOvaJEjKdlVzUBh4l/g6PPG KHftCylEwwZ6ll1g04SLaugM4UquvAdAdMVTYXubRjmDq7WK+ezTisMuC5qjC0nCzRx7 o0UBuhgR5f62eFGlGiLb1xE4m4z/M/Inpr39bLYaaAOc+W3LdpLrH26SEbp953kpEQgi hAhA== 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=zEPNGRivVbds9plHiKXTNoXqZ1vyUAijkxR3WfY4Bwk=; b=JHTqDlqqUqddtdN9Rbeu1Qt16XPNLHDsYPKvdwQa9WikSR6nGWyu6MFixSi9dDxSK9 VkWyLGIeutCPUS46YH58kZ/2rMBk3zG2v/KldYcwFNnXQQXU/9m3cy6kERzX9D0ar+le AQbtNYHPYHhq9JP6h/xGMuvwyr/bZYAs1oeXGH32qB42Gl5cOZybMVNwIXYxzyklJAbb zMt/+tJjpOI80QddFkA/HrGI/PuBr6iLDy/Gq2nVK/VEcyUSGKFGQf69dcqCap4gjDap XiBbcJSk94wsSxh57Gpr5Z8LqgSgJPr5v/I5jMM6Fqrujh+nbRAlqeDcRvrhPOFgDmli jGxg== X-Gm-Message-State: AOAM530xk3swzzfSpTuKGAOhI6QJUT5+nl54P/ll75vuFWGfAUSKSzOv WCfINScxPF6mCtnrwZnhjQOBQqqMeuA4K/Sl7L9lIzeItuM= X-Google-Smtp-Source: ABdhPJwnuTbrJ2tO2/xJVuHVAitYONxDa2+4Zv8rp3Boh0ONXI0ZtgCvh0LQt50Y5j3+mARMnsJui/Rt9BEXKq1GDJw= X-Received: by 2002:a05:6602:2e87:: with SMTP id m7mr495939iow.203.1591121579717; Tue, 02 Jun 2020 11:12:59 -0700 (PDT) MIME-Version: 1.0 References: <158983448603.3400.6838657620034200956@ietfa.amsl.com> In-Reply-To: From: CARLOS JESUS BERNARDOS CANO Date: Tue, 2 Jun 2020 20:12:43 +0200 Message-ID: To: =?UTF-8?B?56We5piO6YGU5ZOJ?= Cc: dhcwg , "" , draft-ietf-dhc-slap-quadrant.all@ietf.org, last-call@ietf.org Content-Type: multipart/alternative; boundary="0000000000008deadd05a71ddc82" Archived-At: Subject: Re: [Int-dir] [dhcwg] Intdir last call review of draft-ietf-dhc-slap-quadrant-08 X-BeenThere: int-dir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This list is for discussion between the members of the Internet Area directorate." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Jun 2020 18:13:03 -0000 --0000000000008deadd05a71ddc82 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable OK, thanks again for your review! Carlos On Tue, Jun 2, 2020 at 8:04 PM =E7=A5=9E=E6=98=8E=E9=81=94=E5=93=89 wrote: > At Tue, 2 Jun 2020 17:40:47 +0200, > CARLOS JESUS BERNARDOS CANO wrote: > > > > > > 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). > > I thought the server doesn't make a new assignment for IA_NA or IA_PD > when the server finds the lifetimes of the currently (IPv6) address or > prefix cannot be extended. And I thought this specification somehow > deliberately differs from these cases. But on re-reading RFC8415 I've > noticed this: > > The server may choose to change the list of addresses or delegated > prefixes and the lifetimes in IAs that are returned to the client. > > It doesn't seem to discuss the implication of being unable to extend > the lifetimes regarding this behavior, but I now see that assigning a > different resource (IPv6 address or prefix, or in this draft's case, > L2 address) in response to Renew. > > So please simply ignore this comment. > > -- > JINMEI, Tatuya > --0000000000008deadd05a71ddc82 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
OK, thanks again for your review!

Carlo= s

On Tue, Jun 2, 2020 at 8:04 PM =E7=A5=9E=E6=98=8E=E9=81=94=E5=93=89 = <jinmei@wide.ad.jp> wrote:
At Tue, 2 Jun 202= 0 17:40:47 +0200,
CARLOS JESUS BERNARDOS CANO <cjbc@it.uc3m.es> wrote:

> > > > It's not clear to me what 'the preferred quadra= nts are known for the
> > > > allocation of any "new" addresses' means.= =C2=A0 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 &= quot;new" means)
> > > addresses from the same quadrant. We have added "differ= ent" to the text
> > in
> > > version -09 to make this clearer.
> >
> > Hmm, isn't it different from what the server would do with Re= new for
> > other types of IAs?=C2=A0 (Assuming that's correct) being dif= ferent 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).

I thought the server doesn't make a new assignment for IA_NA or IA_PD when the server finds the lifetimes of the currently (IPv6) address or
prefix cannot be extended.=C2=A0 And I thought this specification somehow deliberately differs from these cases.=C2=A0 But on re-reading RFC8415 I= 9;ve
noticed this:

=C2=A0 =C2=A0The server may choose to change the list of addresses or deleg= ated
=C2=A0 =C2=A0prefixes and the lifetimes in IAs that are returned to the cli= ent.

It doesn't seem to discuss the implication of being unable to extend the lifetimes regarding this behavior, but I now see that assigning a
different resource (IPv6 address or prefix, or in this draft's case, L2 address) in response to Renew.

So please simply ignore this comment.

--
JINMEI, Tatuya
--0000000000008deadd05a71ddc82-- From nobody Wed Jun 3 11:29:58 2020 Return-Path: X-Original-To: int-dir@ietf.org Delivered-To: int-dir@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id E162D3A0EA2; Wed, 3 Jun 2020 11:29:49 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Tatuya Jinmei via Datatracker To: Cc: dhcwg@ietf.org, draft-ietf-dhc-mac-assign.all@ietf.org, last-call@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.1.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <159120898987.8437.4415340061530507051@ietfa.amsl.com> Reply-To: Tatuya Jinmei Date: Wed, 03 Jun 2020 11:29:49 -0700 Archived-At: Subject: [Int-dir] Intdir last call review of draft-ietf-dhc-mac-assign-06 X-BeenThere: int-dir@ietf.org X-Mailman-Version: 2.1.29 List-Id: "This list is for discussion between the members of the Internet Area directorate." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Jun 2020 18:29:56 -0000 Reviewer: Tatuya Jinmei Review result: Ready with Nits I am an assigned INT directorate reviewer for draft-ietf-dhc-mac-assign. These comments were written primarily for the benefit of the Internet Area Directors. Document editors and shepherd(s) should treat these comments just like they would treat comments from any other IETF contributors and resolve them along with any other Last Call comments that have been received. For more details on the INT Directorate, see https://datatracker.ietf.org/group/intdir/about/ . I've reviewed draft-ietf-dhc-mac-assign-06 (07 was submitted while I was reviewing 06, and I also checked 07 on some specific points to see if it's changed, but the check is not comprehensive so some comments may be already moot or addressed.) I think this draft is basically ready. Its purpose and protocol details are well written, and the protocol is generally a straightforward application of the basic DHCPv6 (IP) address assignment protocol as described in RFC8415. I didn't find any obvious problem. My comments are largely editorial. The first one for Section 8 may need some discussion, but I'd basically leave the authors whether/how to address the comments including this one. Specific comments: - Section 1: The IEEE originally set aside half of the 48-bit MAC Address space for local use (where the U/L bit is set to 1). In 2017, the IEEE specified an optional specification (IEEE 802c) that divides this space into quadrants (Standards Assigned Identifier, Extended Local Identifier, Administratively Assigned Identifier, and a Reserved quadrant) - more details are in Appendix A. I wonder whether this paragraph could refer to draft-ietf-dhc-slap-quadrant. - Section 4 Clients implementing this mechanism SHOULD use the Rapid Commit option as specified in Section 5.1 and 18.2.1 of [RFC8415]. Just out of curiosity, what's the rationale of this SHOULD? (It's not obvious to me and) it doesn't seem to be explained anywhere in the draft. - Section 8 [...] The server MUST NOT shrink or expand the address block - once a block is assigned and has a non-zero valid lifetime, its size, starting address, and ending address MUST NOT change. We may need some clarification on the implication of this requirement on the following description of draft-ietf-dhc-slap-quadrant-09: [...] 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" (i.e., different) addresses. (Section 4.1-5) since on the surface of it, this could read as if it's against the MUST NOT. - Section 8 same text as the previous bullet While commenting on the previous point I've noticed one minor possible glitch: while "its size, starting address, and ending address MUST NOT change" prohibits any kind of change to the block, "MUST NOT shrink or expand the address block" sounds like only limiting a particular type of change (shrink or expand). So ,it's not 100% cleear, for example, if changing "start=02:04:06:08:0a, size=1 (extra-addresses=0)" to "start=02:04:06:08:0b, size=1" is allowed or not because this change does not "shrink or expand" the previos block. I believe the actual intent is the latter MUST NOT, i.e., prohibiting any kind of change, so we might rather say: [...] The server MUST NOT change the address block (including shrinking or expanding it) - once a block is assigned and has a non-zero valid lifetime, its size and starting address MUST NOT change. (btw I've removed "ending address" for another editorial cleanup because it seemed redundant - given it's a "block", the "ending address" is determined from the starting address and its size, and the "ending address" doesn't appear in the protocol explicitly). - Section 10 It may be too obvious, but you might want to clarify that the option field values are in network byte order (similar to Section 8 of RFC8415, for example). - Section 10.2 option-len 12 + link-layer-len field (typically 6) + length of "link-layer-len field value" may be better? Nit - Section 7: s/chose/choose/ [...] However, the server MAY chose to ignore some or all parameters of the requested address block. [...] From nobody Wed Jun 3 12:56:49 2020 Return-Path: X-Original-To: int-dir@ietfa.amsl.com Delivered-To: int-dir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B0BD83A0EEF; Wed, 3 Jun 2020 12:56:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.598 X-Spam-Level: X-Spam-Status: No, score=-9.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=NFjAD0IG; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=rqqbxrzy 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 8mROUX9TOwb3; Wed, 3 Jun 2020 12:56:40 -0700 (PDT) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 93BA63A0EEA; Wed, 3 Jun 2020 12:56:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7105; q=dns/txt; s=iport; t=1591214200; x=1592423800; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=nbhocpvAWpMPxs1OuQLGgXONWmHfCCmZUkAE1HtJIK4=; b=NFjAD0IGA04akrNOPDIquyYYHSQ/iHnn7Xo7gfzusNL9KqgEmuWrMQX+ 9RonVt9JDI0+6sXuYlXiN19E6SVOlM6olR9B6qjbH+h0uKed5f5QuC6u5 iyBWVrXX3kkf3psjiS5GPPq61vO3m5aUL3ZFzgV/GsAh+R6cMaIGQFfcs Q=; IronPort-PHdr: =?us-ascii?q?9a23=3AY36QmhAnTAneNpcn9bkSUyQJPHJ1sqjoPgMT9p?= =?us-ascii?q?ssgq5PdaLm5Zn5IUjD/qw00g3WXInWrftIzejO4OjsWm0FtJCGtn1KMJlBTA?= =?us-ascii?q?QMhshemQs8SNWEBkv2IL+PDWQ6Ec1OWUUj8yS9Nk5YS9n/a1CUq3H07yZBUh?= =?us-ascii?q?n6PBB+c+LyHIOahs+r1ue0rpvUZQgAhDe0bb5oahusqgCEvcgNiowkIaE0mR?= =?us-ascii?q?Y=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CUBQAf/9de/4MNJK1mHAEBAQEBAQc?= =?us-ascii?q?BARIBAQQEAQFAgUqBUikpB29YLywKh2EDjUaYUIFCgRADVQsBAQEMAQEYCwo?= =?us-ascii?q?CBAEBhEQCghsCJDgTAgMBAQsBAQUBAQECAQYEbYVbDIVyAQEBAQMBARAoBgE?= =?us-ascii?q?BLAsBCwQCAQgRBAEBHxAnCx0IAgQBDQUIGoI5TIJLAy4BDqRXAoE5iGF0gTS?= =?us-ascii?q?DAQEBBYVDGIIOAwaBOIJkiWgaggCBEUOCHy4+gmcBAQOBSAIag0WCLY5ilF+?= =?us-ascii?q?PL4EACoJZiDSGEopOgmeOHoghhRSQcYl+lAoCBAIEBQIOAQEFgWoigVZwFTu?= =?us-ascii?q?CNQEzUBcCDZBADBeDT4UUhUJ0NwIGCAEBAwl8jF0BMF8BAQ?= X-IronPort-AV: E=Sophos;i="5.73,469,1583193600"; d="scan'208";a="519259695" Received: from alln-core-1.cisco.com ([173.36.13.131]) by rcdn-iport-5.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 03 Jun 2020 19:56:38 +0000 Received: from XCH-RCD-002.cisco.com (xch-rcd-002.cisco.com [173.37.102.12]) by alln-core-1.cisco.com (8.15.2/8.15.2) with ESMTPS id 053JucNn026648 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 3 Jun 2020 19:56:38 GMT Received: from xhs-rtp-001.cisco.com (64.101.210.228) by XCH-RCD-002.cisco.com (173.37.102.12) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Wed, 3 Jun 2020 14:56:38 -0500 Received: from xhs-rcd-003.cisco.com (173.37.227.248) by xhs-rtp-001.cisco.com (64.101.210.228) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Wed, 3 Jun 2020 15:56:37 -0400 Received: from NAM10-BN7-obe.outbound.protection.outlook.com (72.163.14.9) by xhs-rcd-003.cisco.com (173.37.227.248) with Microsoft SMTP Server (TLS) id 15.0.1497.2 via Frontend Transport; Wed, 3 Jun 2020 14:56:37 -0500 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=CkOt2eR9Urr1odDERDj2BolJFDfGtAWuH88FPhRi8x52c/n9se8JcNaoEQoIqkLzWRAjMsWeLiwLEj3sV7xq26WKKKkDgO7nrJ2aH1r79aSX/+1Q2WqYLVvlsmQT31gXaxadhYsFc5w5CzL+hqLrxBzZlXmzhFq88V3ZMRxVyiHjJu4SIwsM0lWAl8s9oBZoNqj61M7Pbw7xJIXVemF6fJdk7VO2WQBvmnAPcGzWRoeqlVZrVToe5Pi1yEnvPGUy3q9eqjfvcL9QpX5yqdPDI7PFcZ/vWIsaJHIH5RdwlOHlzZLQ0e+hJKDnY5Zaue7O93/xC/0Qu+L1QZOqWqu+Qg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=Pg5sokLtEFcuNJd19O5mOmeFNUIT/uIJz+H1Q0Mta3I=; b=S8Q2d6Ohe70/kdvid/3NYs579JBdBpgymyAc0XjYxsHpZOXJdUGtG5QaJ8dVUUxOtwK/EwPKn+lrmkPmmOWhJLaaIqhy6qEkG/o2yMFzvHsiLwFvGnMAzEpvNscHms1prh/Puj0gVfVSUNK/RAbncmZ/k7aeIcdZQwj3ttnN/31IX4Zh6ZxVZCiS5GICl+EnXujR7Bk9lADWmcor2uiwhRA5lAJOrzdDZB/YdnpJvkulRIDVWlbCd/RWEeXJKy6lr5cRvoNg6c2Aw/FUC48jzDuZRphHrdJGUtVNHj1gdW0kC25SdWwLv6wIfSP4KsuaLbglVm51v2gnSvLoZLBu+g== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cisco.com; dmarc=pass action=none header.from=cisco.com; dkim=pass header.d=cisco.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=Pg5sokLtEFcuNJd19O5mOmeFNUIT/uIJz+H1Q0Mta3I=; b=rqqbxrzyBxOdsW/7N/Q9trRUoTOcH4SPrEOCRMjhhVCcSzH15fgyI70IFIdoNIuMt+n6jktcuXxpfEclcUts3jLyGZxV5i6DlrXoyWV0pOGymYqwPuKWOwl9BQcsBgFuDTMOZ/bNN2WB3hHAO2L/azHwwPiwf7ye29pDLaIXxCk= Received: from BN7PR11MB2547.namprd11.prod.outlook.com (2603:10b6:406:af::18) by BN7PR11MB2754.namprd11.prod.outlook.com (2603:10b6:406:b3::30) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3066.18; Wed, 3 Jun 2020 19:56:36 +0000 Received: from BN7PR11MB2547.namprd11.prod.outlook.com ([fe80::7d1c:98b:2131:d35]) by BN7PR11MB2547.namprd11.prod.outlook.com ([fe80::7d1c:98b:2131:d35%3]) with mapi id 15.20.3066.018; Wed, 3 Jun 2020 19:56:36 +0000 From: "Bernie Volz (volz)" To: Tatuya Jinmei , "int-dir@ietf.org" CC: "dhcwg@ietf.org" , "draft-ietf-dhc-mac-assign.all@ietf.org" , "last-call@ietf.org" Thread-Topic: [Int-dir] Intdir last call review of draft-ietf-dhc-mac-assign-06 Thread-Index: AQHWOdUYOfm3Pv5X0UOpbrwuLsmiW6jHQ7hQ Date: Wed, 3 Jun 2020 19:56:35 +0000 Message-ID: References: <159120898987.8437.4415340061530507051@ietfa.amsl.com> In-Reply-To: <159120898987.8437.4415340061530507051@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: wide.ad.jp; dkim=none (message not signed) header.d=none;wide.ad.jp; dmarc=none action=none header.from=cisco.com; x-originating-ip: [173.38.117.66] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: edb559ba-0314-4483-b704-08d807f838ee x-ms-traffictypediagnostic: BN7PR11MB2754: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-forefront-prvs: 04238CD941 x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: b+5zGT6mLqdfip+nM8XyYvZDU1HhTNcDrmDMEKqGcgpG+uNn/W1zT361kwqg8cAGhX3EugBTJcZ9sXQy1Ki/I239zvtk2KwcxuZs5+I0neS3oRspe4QhBDdsPLrVrnRRFtjN7sXAO4TLLUB1QmfIQt2fjdzCHWZjGIEUHDYGTubowEgXgBOOtF8OQKQVX3h0yaC0CTXRL74GuXWX1u/sVq8j86nuoKMuHuAlU34OOL0t8T+EGJj+YlBaxB8zhci+zILLz8nVlU4DcVBR/5EyhUcb0tRnmYbwbBxZroEL3/rA5LjG6LARCKrLfKEcCqc+aYiFb0HhTlvn879op8FCx07klDoLdsiwIWC42NG6w1jgzcYo8xrtZqJ4mbKL1REsAzV34hOdH1Lwn7+JIyaNNw== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:BN7PR11MB2547.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(366004)(346002)(396003)(136003)(39860400002)(376002)(33656002)(52536014)(8936002)(55016002)(83380400001)(26005)(8676002)(6506007)(66946007)(76116006)(110136005)(66446008)(186003)(5660300002)(2906002)(53546011)(66476007)(64756008)(66556008)(54906003)(71200400001)(9686003)(316002)(7696005)(478600001)(4326008)(966005)(66574014)(86362001); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: eKECAnrRxGKrKPsinEzq4jA6/5/iBu5afl/Mvuymh6zxJKMSLG45dVDnqut73EANMbHJfDZLfIjq8+HjbM9X3jOq14zH87W7ez6+/bS3l08ehBGrjHeSX4r7Cc+8VZaRZ/liDW+aFOijaUsCKCVF559ECsbmXEGssZUGKc/U4e7L9x3W56zzxonjJlI7+pQ+vu5GB0qTk05OFN0Mq8UaOwLKXzPt7mLA8HccZoag1uLnN6ZYoZ1ioE4jh6wL2daAlWaiI3BchPB4BVL3wUUrl3ooOr7f+ebs4yZ1B6y44yJ9IiFfAqn2a5ic4dv1enL8gYGKPkVfhGJgVIKpSzxs7lZ+t4Em5j6ah4ka90kpmeuaenwX1a4ClHuowWhm4L7VA0RmNeR2VJzMPQYt81qdbf3jio23RgPUm7A7h+IAaSYj3XON8IzpZMC/+Sf6e8LMSx8x/v9fSvBGvWgIETp/iDC+PNgbtiQ2OGzu+FYmRFfvVPz+aC/1PgYrZ0nafOEo x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: edb559ba-0314-4483-b704-08d807f838ee X-MS-Exchange-CrossTenant-originalarrivaltime: 03 Jun 2020 19:56:36.0567 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: XYSpJONaV9al0fdJhUVt5WrnI0T3Qlsb3a4it0roH1Doc3E8/Kgkn72OmLcXkSki X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN7PR11MB2754 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.37.102.12, xch-rcd-002.cisco.com X-Outbound-Node: alln-core-1.cisco.com Archived-At: Subject: Re: [Int-dir] Intdir last call review of draft-ietf-dhc-mac-assign-06 X-BeenThere: int-dir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This list is for discussion between the members of the Internet Area directorate." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Jun 2020 19:56:43 -0000 Hi Jinmei. Thanks much for the review! Comments below (BV>). Carlos may also have some. As these are fairly minor, I will queue them up for a -08 as there may be m= ore discussion on these comments and/or IESG reviews may raise some additio= nal issues. - Bernie -----Original Message----- From: Int-dir On Behalf Of Tatuya Jinmei via Dat= atracker Sent: Wednesday, June 3, 2020 2:30 PM To: int-dir@ietf.org Cc: dhcwg@ietf.org; draft-ietf-dhc-mac-assign.all@ietf.org; last-call@ietf.= org Subject: [Int-dir] Intdir last call review of draft-ietf-dhc-mac-assign-06 Reviewer: Tatuya Jinmei Review result: Ready with Nits I am an assigned INT directorate reviewer for draft-ietf-dhc-mac-assign. Th= ese comments were written primarily for the benefit of the Internet Area Di= rectors. Document editors and shepherd(s) should treat these comments just like they would treat comments= from any other IETF contributors and resolve them along with any other Las= t Call comments that have been received. For more details on the INT Direct= orate, see https://datatracker.ietf.org/group/intdir/about/ . I've reviewed draft-ietf-dhc-mac-assign-06 (07 was submitted while I was re= viewing 06, and I also checked 07 on some specific points to see if it's ch= anged, but the check is not comprehensive so some comments may be already m= oot or addressed.) I think this draft is basically ready. Its purpose and= protocol details are well written, and the protocol is generally a straigh= tforward application of the basic DHCPv6 (IP) address assignment protocol as described in RFC8415. I didn't = find any obvious problem. My comments are largely editorial. The first one for Section 8 may need so= me discussion, but I'd basically leave the authors whether/how to address t= he comments including this one. Specific comments: - Section 1: The IEEE originally set aside half of the 48-bit MAC Address space for local use (where the U/L bit is set to 1). In 2017, the IEEE specified an optional specification (IEEE 802c) that divides this space into quadrants (Standards Assigned Identifier, Extended Local Identifier, Administratively Assigned Identifier, and a Reserved quadrant) - more details are in Appendix A. I wonder whether this paragraph could refer to draft-ietf-dhc-slap-quadrant= . BV> Technically this was just a historical perspective as to what IEEE did.= We do reference the slap-quadrant elsewhere. - Section 4 Clients implementing this mechanism SHOULD use the Rapid Commit option as specified in Section 5.1 and 18.2.1 of [RFC8415]. Just out of curiosity, what's the rationale of this SHOULD? (It's not obvi= ous to me and) it doesn't seem to be explained anywhere in the draft. BV> We thought this would be useful as the server(s) can decide whether to = honor or not and fewer packets (i.e., no Request/Reply exchange) would be b= eneficial. I guess we could say: Clients implementing this mechanism SHOULD use the Rapid Commit option as specified in Section 5.1 and 18.2.1 of [RFC8415] to obtain addresses with a 2-message exchange when possible. BV> This expedites the client using the final address. Technically it is le= ss critical for the hypervisor case, but it shouldn't hurt. - Section 8 [...] The server MUST NOT shrink or expand the address block - once a block is assigned and has a non-zero valid lifetime, its size, starting address, and ending address MUST NOT change. We may need some clarification on the implication of this requirement on th= e following description of draft-ietf-dhc-slap-quadrant-09: [...] 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" (i.e., different) addresses. (Section 4.1-5) since on the surface of it, this could read as if it's against the MUST NOT= . BV> This is the case that the old lease may not be desired anymore (i.e., s= erver policy change or an administrative request for the lease to no longer= be extended) and so the server needs to know the quadrant details to assig= n a new allocation. See below regarding your example. This is normal DHCPv= 6 renumbering and letting an old lease expire while providing a new one. Wi= th link-layer addresses, when the client switches (as I doubt it would want= to use both) is up to it (immediately or on expiration of the valid lifeti= me of the old). - Section 8 same text as the previous bullet While commenting on the previous point I've noticed one minor possible glitch: while "its size, starting address, and ending address MUST NOT chan= ge" prohibits any kind of change to the block, "MUST NOT shrink or expand t= he address block" sounds like only limiting a particular type of change (sh= rink or expand). So ,it's not 100% cleear, for example, if changing "start= =3D02:04:06:08:0a, size=3D1 (extra-addresses=3D0)" to "start=3D02:04:06:08:= 0b, size=3D1" is allowed or not because this change does not "shrink or exp= and" the previos block. I believe the actual intent is the latter MUST NOT= , i.e., prohibiting any kind of change, so we might rather say: [...] The server MUST NOT change the address block (including shrinkin= g or expanding it) - once a block is assigned and has a non-zero valid lif= etime, its size and starting address MUST NOT change. (btw I've removed "ending address" for another editorial cleanup because it= seemed redundant - given it's a "block", the "ending address" is determine= d from the starting address and its size, and the "ending address" doesn't = appear in the protocol explicitly). BV> FYI "start=3D02:04:06:08:0b, size=3D1" would be a NEW block (for exampl= e, this could be a renumbering event - for some reason the old block should= stop being used when the valid lifetime runs out). I think that the text i= s clear enough as it is - the most common action that someone might think t= o do is to shrink or expand the size but the text already includes the othe= r prohibitions. No other reviewers have had issues with this text. - Section 10 It may be too obvious, but you might want to clarify that the option field = values are in network byte order (similar to Section 8 of RFC8415, for exam= ple). BV> Yeah, I think as these are DHCPv6 options the base standard is already = clear on this. - Section 10.2 option-len 12 + link-layer-len field (typically 6) + length of "link-layer-len field value" may be better? BV> OK. Nit - Section 7: s/chose/choose/ [...] However, the server MAY chose to ignore some or all parameters of the requested address block. [...] BV> OK. _______________________________________________ Int-dir mailing list Int-dir@ietf.org https://www.ietf.org/mailman/listinfo/int-dir From nobody Thu Jun 4 07:30:12 2020 Return-Path: X-Original-To: int-dir@ietfa.amsl.com Delivered-To: int-dir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4DF503A0A8C; Thu, 4 Jun 2020 07:30:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.598 X-Spam-Level: X-Spam-Status: No, score=-9.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=e/J0+Kai; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=sxN6jo2W 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 O3oMYWCiKt7p; Thu, 4 Jun 2020 07:30:09 -0700 (PDT) Received: from alln-iport-7.cisco.com (alln-iport-7.cisco.com [173.37.142.94]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 099F43A003B; Thu, 4 Jun 2020 07:29:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7628; q=dns/txt; s=iport; t=1591280983; x=1592490583; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=tocsyOHanWkcxvUsUkxegB1ye3LCUwNT0Ny4GyEFZUg=; b=e/J0+KaiS4iuAI1ksorWlkZGooKIs3LWyt9Ap2cPJp9w6yP+MM3jssMr JJh/20Ak2Hu1DuF7HJfyr0YPHhyJGDRWY/n7Wo0dx8kJH7wWmjRiBqOLD 2Zc60FDamfpPlZi6Szqffe4QN9C6Act8VdxBp2YF4G6F+nNbA9neGhvvB U=; IronPort-PHdr: =?us-ascii?q?9a23=3AzuJqUBMpoFV8n3hidnIl6mtXPHoupqn0MwgJ65?= =?us-ascii?q?Eul7NJdOG58o//OFDEvKwz3kDIUYid4v4CifKF+6zjWGlV55GHvThCdZFXTB?= =?us-ascii?q?YKhI0QmBBoG8+KD0D3bZuIJyw3FchPThlpqne8N0UGB8fyahvbrjuw9W1aFh?= =?us-ascii?q?D2LwEgIOPzF8bbhNi20Obn/ZrVbk1IiTOxbKk0Ig+xqFDat9Idhs1pLaNixw?= =?us-ascii?q?=3D=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DgAQAfBNle/40NJK1mGwEBAQEBAQE?= =?us-ascii?q?BBQEBARIBAQEDAwEBAUCBSoFSUgdvWC8shCWDRgONP5hQgUKBEANVCwEBAQw?= =?us-ascii?q?BARgLCgIEAQGERAIXghQCJDgTAgMBAQsBAQUBAQECAQYEbYVbDIVyAQEBAQM?= =?us-ascii?q?BARAREQwBASwLAQsEAgEIEQMBAgMCJgICAiULFAEICAIEAQ0FIoMEAYJLAy4?= =?us-ascii?q?BDqQZAoE5iGF2gTKDAQEBBYVDGIIOAwaBDiqCZIloGoFBP4ERJxyCHy4+gmc?= =?us-ascii?q?BAQOBSAIYgxQzgi2OY4MfoHKBAAqCWYg1hhWFVIRcAx2CZ44ejTWQdIl+lAo?= =?us-ascii?q?CBAIEBQIOAQEFgWoigVZwFTsqAYIKATNQFwINkECDcoUUhUJ0NwIGAQcBAQM?= =?us-ascii?q?JfI4tXwEB?= X-IronPort-AV: E=Sophos;i="5.73,472,1583193600"; d="scan'208";a="490644979" Received: from alln-core-8.cisco.com ([173.36.13.141]) by alln-iport-7.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 04 Jun 2020 14:29:42 +0000 Received: from XCH-RCD-001.cisco.com (xch-rcd-001.cisco.com [173.37.102.11]) by alln-core-8.cisco.com (8.15.2/8.15.2) with ESMTPS id 054ETfgK015188 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 4 Jun 2020 14:29:42 GMT Received: from xhs-rcd-002.cisco.com (173.37.227.247) by XCH-RCD-001.cisco.com (173.37.102.11) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Thu, 4 Jun 2020 09:29:41 -0500 Received: from xhs-rtp-003.cisco.com (64.101.210.230) by xhs-rcd-002.cisco.com (173.37.227.247) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Thu, 4 Jun 2020 09:29:41 -0500 Received: from NAM04-BN3-obe.outbound.protection.outlook.com (64.101.32.56) by xhs-rtp-003.cisco.com (64.101.210.230) with Microsoft SMTP Server (TLS) id 15.0.1497.2 via Frontend Transport; Thu, 4 Jun 2020 10:29:41 -0400 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=EHG1tnOi/9Qcx9PFN5t23zY9iqK2zGVvnPFXyQAOchFzeXDgop+DAIXTl0WxTUflS8Obt35rSy/X/I3VGAIYrTXsJPVm5349yqsiqtmb0f1YWEJSOEGy+fY1/YV9M7YnN0j/a2LO8aJ8HodjGzuA6OxDF6hiUvTIp/b8IxLBbfz8eYcWtT/u/d+r2BzZm9JutmdWHwGa2MPQjw6LEZywVc/EH4NbDINu0CRFRbb/TSHPU3EU8GDV23+V4RD1nhwn/Rrjg8aaoS9zAYqWy/7TgxV/BWzHMXtMXuyAI/RWYzxGnhbh2U2CrOXcCx0PyFS46PMFZTaj5I5PUZrBjBvpkA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=tocsyOHanWkcxvUsUkxegB1ye3LCUwNT0Ny4GyEFZUg=; b=TsAYzYP0TxkMb057MZYVtAW9kFMmbRbzlpFrUjK8MEjtg9iGKljHZpK26l8+CTCs7J5vALs6++Xu0rmVQItcZGaHiEuj6QYQ79GX309ibOLaaAfsgrBshh8Ixo5qrEz9VQRVlcp7rXrW2kgi5tWHOQT5AcG9Ob5WjIfY9Cpo57QalCoeYu1j6OGWN/mhYaua69sUPmSfOiD+6A+/E64/8OjDNG8KOpqipe8wSi3uVI1krJu5U5eu9k8oKVgOuyPag9owqyvtNokZC1sGPOxHWmqKI+XjpNAxdNPWGF5YGgDcQSPS1iT+cHHm5a0Qj9ywhAlR/O+/DSloPm8nuYVR9g== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cisco.com; dmarc=pass action=none header.from=cisco.com; dkim=pass header.d=cisco.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=tocsyOHanWkcxvUsUkxegB1ye3LCUwNT0Ny4GyEFZUg=; b=sxN6jo2WGmItwThwPLf/Y7Nm1G5gtRYtyfr8y34qzUwwnvDrBL3hsD/HvlUU/n1M760i0Gw4vkVSoaKzedRgDn8CA6hEawNvn4LEfv/vhpLSXxk9X//r+IUTMzuCfP6RzCk5IzNJGZG24QyCy/kPBf5Y9LcN/SfOsolPjGDSV5I= Received: from DM5PR11MB1753.namprd11.prod.outlook.com (2603:10b6:3:10d::13) by DM5PR11MB1609.namprd11.prod.outlook.com (2603:10b6:4:8::12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3066.18; Thu, 4 Jun 2020 14:29:39 +0000 Received: from DM5PR11MB1753.namprd11.prod.outlook.com ([fe80::a14c:59b6:47b0:f630]) by DM5PR11MB1753.namprd11.prod.outlook.com ([fe80::a14c:59b6:47b0:f630%7]) with mapi id 15.20.3066.018; Thu, 4 Jun 2020 14:29:39 +0000 From: "Eric Vyncke (evyncke)" To: Tatuya Jinmei , "int-dir@ietf.org" CC: "dhcwg@ietf.org" , "draft-ietf-dhc-mac-assign.all@ietf.org" , "last-call@ietf.org" Thread-Topic: [Int-dir] Intdir last call review of draft-ietf-dhc-mac-assign-06 Thread-Index: AQHWOdUYGM/CnuEwnE673cqY5ZrAJajIpwWA Date: Thu, 4 Jun 2020 14:29:39 +0000 Message-ID: <2C3E6375-51E1-49B5-B044-396946A2BA92@cisco.com> References: <159120898987.8437.4415340061530507051@ietfa.amsl.com> In-Reply-To: <159120898987.8437.4415340061530507051@ietfa.amsl.com> Accept-Language: fr-BE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/16.37.20051002 authentication-results: wide.ad.jp; dkim=none (message not signed) header.d=none;wide.ad.jp; dmarc=none action=none header.from=cisco.com; x-originating-ip: [2001:420:c0c1:36:a0f1:58e8:99ef:8a8f] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 97ac8fd4-18da-49e6-8dab-08d80893b6f2 x-ms-traffictypediagnostic: DM5PR11MB1609: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-forefront-prvs: 04244E0DC5 x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: f7skSa3G8OzYzqOkuxYQXon10smHXeJoS8CD+PzaJkj1jf7Hbnv27GRrTO4VQvXqrhn9ZbGO0k9aYPIowQINVUpvpWhMSBIkd6UyHAjOT7NQHiqd7YDHoNo8EfwvCb5PEtaXsRrG9A8nwjJg/vWkJeDeRAgiRqhJPnH8Zt3QwruALRkjJFwNvi2IxTS31RaPclo6xRRW1M3W49PTCFZkPDegdCAnaUp6s4A4De1yX798GGhgF/zv4X/hHNkKi86hkmsp9bG+Fje2IWFxDA1QPYN3jbobgTVrnzpRt+/SuMnT4WLu/JDi5IUitFiIkZvb1LG9coZIsbFwsmT9/5RseCAmKh5F7uVw9gUnvtDI2VZ/WolDW2FiVuQKmamY9Xu5mGzOtYMqbjepqeJe36JayA== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DM5PR11MB1753.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(366004)(396003)(39860400002)(136003)(346002)(376002)(966005)(4326008)(186003)(6506007)(316002)(478600001)(33656002)(66556008)(53546011)(66446008)(8936002)(66476007)(8676002)(2616005)(2906002)(71200400001)(66574014)(66946007)(76116006)(64756008)(91956017)(83380400001)(86362001)(6486002)(6512007)(54906003)(110136005)(36756003)(5660300002); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: UOMVOVNMLupSrOjCHUMaWlo8vW/ApCykoe2hXd5ysM/cX4JeDnXr88zYI7JjykU/Gk7fVcdEqNaGpR/6uWvpmEmuwAfZWe1vmWTGvLplrQgj1idg5MCMnFW17M7ajFSmaFlZaMKJTZqkMzFz5G8l6sxEBVD2j030mBRA5xp9qSNXWFh39ih02uVjPJXVc5QT46YQiHWry3WfBiKHBUtjTgHQW3MBsIwhexzOJfVcMVBb8ucezUVkLr2fIis3RQUoiuIwZ616/7GyxabM3jcwLm5xtDxafouXmBYRaI18ZFQPZfI48ifoae1TEgjCdBR1mj0MAFzx8N2oLPcEMvz77TTr3LaMDRgiyX2ekLQ49Uk0uyqV/zet1QWebNI5np3xafksYLi4TvVtY0s9PfrzBBAAwdTjbasvaWmAqyok2Apci4+I7eOBK2Otva/HljjyPDpJmAfIFCSt0UClYBtHS6oXzHiQatO/2Ho4//1IzOA8t8Fek0VWqbsH8001tHBfsniFEDbZZ7QsIeo+A+BTN5rJD9E0FvRW+uC5KBdO+Ck= x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 97ac8fd4-18da-49e6-8dab-08d80893b6f2 X-MS-Exchange-CrossTenant-originalarrivaltime: 04 Jun 2020 14:29:39.4279 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: YFiSZ2coHYKicrBuzIu2HjKcNi8skxW9lczL0rDbVe4lgOLvEP8MSxDMYmUTn5CW52jwI4g4PznhP3U0QE2wPw== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR11MB1609 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.37.102.11, xch-rcd-001.cisco.com X-Outbound-Node: alln-core-8.cisco.com Archived-At: Subject: Re: [Int-dir] Intdir last call review of draft-ietf-dhc-mac-assign-06 X-BeenThere: int-dir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This list is for discussion between the members of the Internet Area directorate." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Jun 2020 14:30:11 -0000 VGhhbmsgeW91IEppbm1laSBmb3IgdGhlIHJldmlldy4gSSB3aWxsIG1ha2Ugc3VyZSB0aGF0IHlv dXIgY29tbWVudHMgYXJlIHJlZmxlY3RlZCBpbiB0aGUgdGVsZWNoYXQNCg0KLcOpcmljDQoNCu+7 vy0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBJbnQtZGlyIDxpbnQtZGlyLWJvdW5j ZXNAaWV0Zi5vcmc+IG9uIGJlaGFsZiBvZiBUYXR1eWEgSmlubWVpIHZpYSBEYXRhdHJhY2tlciA8 bm9yZXBseUBpZXRmLm9yZz4NClJlcGx5LVRvOiBUYXR1eWEgSmlubWVpIDxqaW5tZWlAd2lkZS5h ZC5qcD4NCkRhdGU6IFdlZG5lc2RheSwgMyBKdW5lIDIwMjAgYXQgMjA6MzANClRvOiAiaW50LWRp ckBpZXRmLm9yZyIgPGludC1kaXJAaWV0Zi5vcmc+DQpDYzogImRoY3dnQGlldGYub3JnIiA8ZGhj d2dAaWV0Zi5vcmc+LCAiZHJhZnQtaWV0Zi1kaGMtbWFjLWFzc2lnbi5hbGxAaWV0Zi5vcmciIDxk cmFmdC1pZXRmLWRoYy1tYWMtYXNzaWduLmFsbEBpZXRmLm9yZz4sICJsYXN0LWNhbGxAaWV0Zi5v cmciIDxsYXN0LWNhbGxAaWV0Zi5vcmc+DQpTdWJqZWN0OiBbSW50LWRpcl0gSW50ZGlyIGxhc3Qg Y2FsbCByZXZpZXcgb2YgZHJhZnQtaWV0Zi1kaGMtbWFjLWFzc2lnbi0wNg0KDQogICAgUmV2aWV3 ZXI6IFRhdHV5YSBKaW5tZWkNCiAgICBSZXZpZXcgcmVzdWx0OiBSZWFkeSB3aXRoIE5pdHMNCg0K ICAgIEkgYW0gYW4gYXNzaWduZWQgSU5UIGRpcmVjdG9yYXRlIHJldmlld2VyIGZvcg0KICAgIGRy YWZ0LWlldGYtZGhjLW1hYy1hc3NpZ24uIFRoZXNlIGNvbW1lbnRzIHdlcmUgd3JpdHRlbiBwcmlt YXJpbHkgZm9yDQogICAgdGhlIGJlbmVmaXQgb2YgdGhlIEludGVybmV0IEFyZWEgRGlyZWN0b3Jz LiBEb2N1bWVudCBlZGl0b3JzIGFuZA0KICAgIHNoZXBoZXJkKHMpIHNob3VsZCB0cmVhdCB0aGVz ZSBjb21tZW50cyBqdXN0IGxpa2UgdGhleSB3b3VsZCB0cmVhdA0KICAgIGNvbW1lbnRzIGZyb20g YW55IG90aGVyIElFVEYgY29udHJpYnV0b3JzIGFuZCByZXNvbHZlIHRoZW0gYWxvbmcgd2l0aA0K ICAgIGFueSBvdGhlciBMYXN0IENhbGwgY29tbWVudHMgdGhhdCBoYXZlIGJlZW4gcmVjZWl2ZWQu IEZvciBtb3JlIGRldGFpbHMNCiAgICBvbiB0aGUgSU5UIERpcmVjdG9yYXRlLCBzZWUgaHR0cHM6 Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9ncm91cC9pbnRkaXIvYWJvdXQvIC4NCg0KICAgIEkndmUg cmV2aWV3ZWQgZHJhZnQtaWV0Zi1kaGMtbWFjLWFzc2lnbi0wNiAoMDcgd2FzIHN1Ym1pdHRlZCB3 aGlsZSBJDQogICAgd2FzIHJldmlld2luZyAwNiwgYW5kIEkgYWxzbyBjaGVja2VkIDA3IG9uIHNv bWUgc3BlY2lmaWMgcG9pbnRzIHRvIHNlZQ0KICAgIGlmIGl0J3MgY2hhbmdlZCwgYnV0IHRoZSBj aGVjayBpcyBub3QgY29tcHJlaGVuc2l2ZSBzbyBzb21lIGNvbW1lbnRzDQogICAgbWF5IGJlIGFs cmVhZHkgbW9vdCBvciBhZGRyZXNzZWQuKSAgSSB0aGluayB0aGlzIGRyYWZ0IGlzIGJhc2ljYWxs eQ0KICAgIHJlYWR5LiAgSXRzIHB1cnBvc2UgYW5kIHByb3RvY29sIGRldGFpbHMgYXJlIHdlbGwg d3JpdHRlbiwgYW5kIHRoZQ0KICAgIHByb3RvY29sIGlzIGdlbmVyYWxseSBhIHN0cmFpZ2h0Zm9y d2FyZCBhcHBsaWNhdGlvbiBvZiB0aGUgYmFzaWMNCiAgICBESENQdjYgKElQKSBhZGRyZXNzIGFz c2lnbm1lbnQgcHJvdG9jb2wgYXMgZGVzY3JpYmVkIGluIFJGQzg0MTUuICBJDQogICAgZGlkbid0 IGZpbmQgYW55IG9idmlvdXMgcHJvYmxlbS4NCg0KICAgIE15IGNvbW1lbnRzIGFyZSBsYXJnZWx5 IGVkaXRvcmlhbC4gIFRoZSBmaXJzdCBvbmUgZm9yIFNlY3Rpb24gOCBtYXkNCiAgICBuZWVkIHNv bWUgZGlzY3Vzc2lvbiwgYnV0IEknZCBiYXNpY2FsbHkgbGVhdmUgdGhlIGF1dGhvcnMgd2hldGhl ci9ob3cNCiAgICB0byBhZGRyZXNzIHRoZSBjb21tZW50cyBpbmNsdWRpbmcgdGhpcyBvbmUuDQoN CiAgICBTcGVjaWZpYyBjb21tZW50czoNCg0KICAgIC0gU2VjdGlvbiAxOg0KDQogICAgICAgVGhl IElFRUUgb3JpZ2luYWxseSBzZXQgYXNpZGUgaGFsZiBvZiB0aGUgNDgtYml0IE1BQyBBZGRyZXNz IHNwYWNlDQogICAgICAgZm9yIGxvY2FsIHVzZSAod2hlcmUgdGhlIFUvTCBiaXQgaXMgc2V0IHRv IDEpLiAgSW4gMjAxNywgdGhlIElFRUUNCiAgICAgICBzcGVjaWZpZWQgYW4gb3B0aW9uYWwgc3Bl Y2lmaWNhdGlvbiAoSUVFRSA4MDJjKSB0aGF0IGRpdmlkZXMgdGhpcw0KICAgICAgIHNwYWNlIGlu dG8gcXVhZHJhbnRzIChTdGFuZGFyZHMgQXNzaWduZWQgSWRlbnRpZmllciwgRXh0ZW5kZWQgTG9j YWwNCiAgICAgICBJZGVudGlmaWVyLCBBZG1pbmlzdHJhdGl2ZWx5IEFzc2lnbmVkIElkZW50aWZp ZXIsIGFuZCBhIFJlc2VydmVkDQogICAgICAgcXVhZHJhbnQpIC0gbW9yZSBkZXRhaWxzIGFyZSBp biBBcHBlbmRpeCBBLg0KDQogICAgSSB3b25kZXIgd2hldGhlciB0aGlzIHBhcmFncmFwaCBjb3Vs ZCByZWZlciB0byBkcmFmdC1pZXRmLWRoYy1zbGFwLXF1YWRyYW50Lg0KDQogICAgLSBTZWN0aW9u IDQNCg0KICAgICAgIENsaWVudHMgaW1wbGVtZW50aW5nIHRoaXMgbWVjaGFuaXNtIFNIT1VMRCB1 c2UgdGhlIFJhcGlkIENvbW1pdA0KICAgICAgIG9wdGlvbiBhcyBzcGVjaWZpZWQgaW4gU2VjdGlv biA1LjEgYW5kIDE4LjIuMSBvZiBbUkZDODQxNV0uDQoNCiAgICBKdXN0IG91dCBvZiBjdXJpb3Np dHksIHdoYXQncyB0aGUgcmF0aW9uYWxlIG9mIHRoaXMgU0hPVUxEPyAgKEl0J3Mgbm90DQogICAg b2J2aW91cyB0byBtZSBhbmQpIGl0IGRvZXNuJ3Qgc2VlbSB0byBiZSBleHBsYWluZWQgYW55d2hl cmUgaW4gdGhlDQogICAgZHJhZnQuDQoNCiAgICAtIFNlY3Rpb24gOA0KDQogICAgICAgWy4uLl0g IFRoZSBzZXJ2ZXIgTVVTVCBOT1Qgc2hyaW5rIG9yIGV4cGFuZCB0aGUgYWRkcmVzcyBibG9jayAt IG9uY2UNCiAgICAgICBhIGJsb2NrIGlzIGFzc2lnbmVkIGFuZCBoYXMgYSBub24temVybyB2YWxp ZCBsaWZldGltZSwgaXRzIHNpemUsDQogICAgICAgc3RhcnRpbmcgYWRkcmVzcywgYW5kIGVuZGlu ZyBhZGRyZXNzIE1VU1QgTk9UIGNoYW5nZS4NCg0KICAgIFdlIG1heSBuZWVkIHNvbWUgY2xhcmlm aWNhdGlvbiBvbiB0aGUgaW1wbGljYXRpb24gb2YgdGhpcyByZXF1aXJlbWVudA0KICAgIG9uIHRo ZSBmb2xsb3dpbmcgZGVzY3JpcHRpb24gb2YgZHJhZnQtaWV0Zi1kaGMtc2xhcC1xdWFkcmFudC0w OToNCg0KICAgICAgICAgICBbLi4uXSAgSXQgaW5jbHVkZXMgdGhlIHByZWZlcnJlZCBTTEFQIHF1 YWRyYW50KHMpIGluIHRoZSBuZXcNCiAgICAgICAgICAgUVVBRCBJQV9MTC1vcHRpb24sIHNvIGlu IGNhc2UgdGhlIHNlcnZlciBpcyB1bmFibGUgdG8gZXh0ZW5kIHRoZQ0KICAgICAgICAgICBsaWZl dGltZSBvbiB0aGUgZXhpc3RpbmcgYWRkcmVzcyhlcyksIHRoZSBwcmVmZXJyZWQgcXVhZHJhbnRz IGFyZQ0KICAgICAgICAgICBrbm93biBmb3IgdGhlIGFsbG9jYXRpb24gb2YgYW55ICJuZXciIChp LmUuLCBkaWZmZXJlbnQpDQogICAgICAgICAgIGFkZHJlc3Nlcy4NCiAgICAoU2VjdGlvbiA0LjEt NSkNCg0KICAgIHNpbmNlIG9uIHRoZSBzdXJmYWNlIG9mIGl0LCB0aGlzIGNvdWxkIHJlYWQgYXMg aWYgaXQncyBhZ2FpbnN0IHRoZQ0KICAgIE1VU1QgTk9ULg0KDQogICAgLSBTZWN0aW9uIDggc2Ft ZSB0ZXh0IGFzIHRoZSBwcmV2aW91cyBidWxsZXQNCg0KICAgIFdoaWxlIGNvbW1lbnRpbmcgb24g dGhlIHByZXZpb3VzIHBvaW50IEkndmUgbm90aWNlZCBvbmUgbWlub3IgcG9zc2libGUNCiAgICBn bGl0Y2g6IHdoaWxlICJpdHMgc2l6ZSwgc3RhcnRpbmcgYWRkcmVzcywgYW5kIGVuZGluZyBhZGRy ZXNzIE1VU1QgTk9UDQogICAgY2hhbmdlIiBwcm9oaWJpdHMgYW55IGtpbmQgb2YgY2hhbmdlIHRv IHRoZSBibG9jaywgIk1VU1QgTk9UIHNocmluayBvcg0KICAgIGV4cGFuZCB0aGUgYWRkcmVzcyBi bG9jayIgc291bmRzIGxpa2Ugb25seSBsaW1pdGluZyBhIHBhcnRpY3VsYXIgdHlwZQ0KICAgIG9m IGNoYW5nZSAoc2hyaW5rIG9yIGV4cGFuZCkuICBTbyAsaXQncyBub3QgMTAwJSBjbGVlYXIsIGZv ciBleGFtcGxlLA0KICAgIGlmIGNoYW5naW5nICJzdGFydD0wMjowNDowNjowODowYSwgc2l6ZT0x IChleHRyYS1hZGRyZXNzZXM9MCkiIHRvDQogICAgInN0YXJ0PTAyOjA0OjA2OjA4OjBiLCBzaXpl PTEiIGlzIGFsbG93ZWQgb3Igbm90IGJlY2F1c2UgdGhpcw0KICAgIGNoYW5nZSBkb2VzIG5vdCAi c2hyaW5rIG9yIGV4cGFuZCIgdGhlIHByZXZpb3MgYmxvY2suICBJIGJlbGlldmUgdGhlDQogICAg YWN0dWFsIGludGVudCBpcyB0aGUgbGF0dGVyIE1VU1QgTk9ULCBpLmUuLCBwcm9oaWJpdGluZyBh bnkga2luZCBvZg0KICAgIGNoYW5nZSwgc28gd2UgbWlnaHQgcmF0aGVyIHNheToNCg0KICAgICAg IFsuLi5dICBUaGUgc2VydmVyIE1VU1QgTk9UIGNoYW5nZSB0aGUgYWRkcmVzcyBibG9jayAoaW5j bHVkaW5nDQogICAgIHNocmlua2luZyBvciBleHBhbmRpbmcgaXQpIC0gb25jZSBhIGJsb2NrIGlz IGFzc2lnbmVkIGFuZCBoYXMgYQ0KICAgICBub24temVybyB2YWxpZCBsaWZldGltZSwgaXRzIHNp emUgYW5kIHN0YXJ0aW5nIGFkZHJlc3MgTVVTVCBOT1QNCiAgICAgY2hhbmdlLg0KDQogICAgKGJ0 dyBJJ3ZlIHJlbW92ZWQgImVuZGluZyBhZGRyZXNzIiBmb3IgYW5vdGhlciBlZGl0b3JpYWwgY2xl YW51cA0KICAgIGJlY2F1c2UgaXQgc2VlbWVkIHJlZHVuZGFudCAtIGdpdmVuIGl0J3MgYSAiYmxv Y2siLCB0aGUgImVuZGluZw0KICAgIGFkZHJlc3MiIGlzIGRldGVybWluZWQgZnJvbSB0aGUgc3Rh cnRpbmcgYWRkcmVzcyBhbmQgaXRzIHNpemUsIGFuZCB0aGUNCiAgICAiZW5kaW5nIGFkZHJlc3Mi IGRvZXNuJ3QgYXBwZWFyIGluIHRoZSBwcm90b2NvbCBleHBsaWNpdGx5KS4NCg0KICAgIC0gU2Vj dGlvbiAxMA0KDQogICAgSXQgbWF5IGJlIHRvbyBvYnZpb3VzLCBidXQgeW91IG1pZ2h0IHdhbnQg dG8gY2xhcmlmeSB0aGF0IHRoZSBvcHRpb24NCiAgICBmaWVsZCB2YWx1ZXMgYXJlIGluIG5ldHdv cmsgYnl0ZSBvcmRlciAoc2ltaWxhciB0byBTZWN0aW9uIDggb2YNCiAgICBSRkM4NDE1LCBmb3Ig ZXhhbXBsZSkuDQoNCiAgICAtIFNlY3Rpb24gMTAuMg0KDQogICAgICAgb3B0aW9uLWxlbiAgICAg IDEyICsgbGluay1sYXllci1sZW4gZmllbGQgKHR5cGljYWxseSA2KSArIGxlbmd0aCBvZg0KDQog ICAgImxpbmstbGF5ZXItbGVuIGZpZWxkIHZhbHVlIiBtYXkgYmUgYmV0dGVyPw0KDQogICAgTml0 DQogICAgLSBTZWN0aW9uIDc6IHMvY2hvc2UvY2hvb3NlLw0KDQogICAgICAgWy4uLl0gSG93ZXZl ciwgdGhlIHNlcnZlcg0KICAgICAgIE1BWSBjaG9zZSB0byBpZ25vcmUgc29tZSBvciBhbGwgcGFy YW1ldGVycyBvZiB0aGUgcmVxdWVzdGVkIGFkZHJlc3MNCiAgICAgICBibG9jay4gWy4uLl0NCg0K DQoNCiAgICBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0K ICAgIEludC1kaXIgbWFpbGluZyBsaXN0DQogICAgSW50LWRpckBpZXRmLm9yZw0KICAgIGh0dHBz Oi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vaW50LWRpcg0KDQo= From nobody Sat Jun 6 03:11:25 2020 Return-Path: X-Original-To: int-dir@ietfa.amsl.com Delivered-To: int-dir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 840DF3A1054 for ; Sat, 6 Jun 2020 03:11:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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=ham 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 Mr6oL3VknbAP for ; Sat, 6 Jun 2020 03:11:20 -0700 (PDT) Received: from mail-il1-x129.google.com (mail-il1-x129.google.com [IPv6:2607:f8b0:4864:20::129]) (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 BDC923A1049 for ; Sat, 6 Jun 2020 03:11:20 -0700 (PDT) Received: by mail-il1-x129.google.com with SMTP id g3so12026426ilq.10 for ; Sat, 06 Jun 2020 03:11:20 -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=/TNWqvnfivqa8qK0njJEnCVD9DwxUWvWNwqcRL2UcZo=; b=NlxzLkYJP5kacgpFYic/JnJ375XMQ5u9zfeFy6HWr2axRGjCWE1DCYjQoe53P/4JYx Fkd3I8XNzoWyNOLhE7lvwigQLETDE4mODm6wi8aRiRmLc+vmmiMRobXCF6RkNFiaTQJE tjSma4n7OLpVWErIdCrYkH+ip8OrmuMmB+iVtVZfgQCTRsi/kioQAntX3jGhGgndHIW7 E8qDSTjTPgckhhf8t6U4G3ti0Kahi4ISPl1cTf/q3tD/SgVl/ftJ30c/WOO7vWlnQHic ttIBU7hU5VR8oMgtQiNVErBMyI5zxb/bsiUcKQ0HPebyo04ZJ8uukWMHVperSK8OYJJU tzxg== 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=/TNWqvnfivqa8qK0njJEnCVD9DwxUWvWNwqcRL2UcZo=; b=uZQoFnZvq7jspfGN2XZy7Wrl3qcHmdAXmialTjfgFUJt3WWPZUhpI/MyOMVQ/gIDIi To0nFtrSz4TH2JFXN3IkknotFC8a35KQSwx6Xl3M29ks5LkwX41aX83bTfYROc6lxKM3 l41SbT4v1UPkhk7ro37y9oOYlcP6KCyv/Gtsfyo/Dg2Bdey9cReelH8/1SFWmxLPeAJF BaMHq8+FLynJV3Wlsvh2vgH0hp7XdUpt5e3GSCMZm3N7n1M7FzzI6CqrGDoCx099giGR 6OELiZwr34YO+1KMqNcNzWGtDC/DwFJi5ez3pr0REj08MsBu6VFMVzCL+RdsuLY7Dx6R 8+2w== X-Gm-Message-State: AOAM531wQQYBwxajFzOzHFhGr9GrEJftFFbcU+T2WvUTXmhKejzm2yPE BZP7+CIcjLPSRD8a81or6bz3DyNW013B4YJOZSIBKQ== X-Google-Smtp-Source: ABdhPJywEmGS3vy0/xseKOlpMgm/rB7PPukWiEqLAIStnwexfaQ+PUBM9UKMvXPmzgOmNnc4DRjEjCaTli6rYykr/xA= X-Received: by 2002:a92:ce47:: with SMTP id a7mr12677874ilr.288.1591438279857; Sat, 06 Jun 2020 03:11:19 -0700 (PDT) MIME-Version: 1.0 References: <159120898987.8437.4415340061530507051@ietfa.amsl.com> In-Reply-To: From: CARLOS JESUS BERNARDOS CANO Date: Sat, 6 Jun 2020 12:11:03 +0200 Message-ID: To: "Bernie Volz (volz)" Cc: Tatuya Jinmei , "int-dir@ietf.org" , "dhcwg@ietf.org" , "draft-ietf-dhc-mac-assign.all@ietf.org" , "last-call@ietf.org" Content-Type: multipart/alternative; boundary="0000000000005a725005a76799af" Archived-At: Subject: Re: [Int-dir] Intdir last call review of draft-ietf-dhc-mac-assign-06 X-BeenThere: int-dir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This list is for discussion between the members of the Internet Area directorate." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Jun 2020 10:11:24 -0000 --0000000000005a725005a76799af Content-Type: text/plain; charset="UTF-8" Hi Jinmei, Bernie, Apologies for the belated e-mail. Thanks Jinmei for the review. I agree with Bernie's responses, thanks for that. Carlos On Wed, Jun 3, 2020 at 9:56 PM Bernie Volz (volz) wrote: > Hi Jinmei. > > Thanks much for the review! > > Comments below (BV>). Carlos may also have some. > > As these are fairly minor, I will queue them up for a -08 as there may be > more discussion on these comments and/or IESG reviews may raise some > additional issues. > > - Bernie > > -----Original Message----- > From: Int-dir On Behalf Of Tatuya Jinmei via > Datatracker > Sent: Wednesday, June 3, 2020 2:30 PM > To: int-dir@ietf.org > Cc: dhcwg@ietf.org; draft-ietf-dhc-mac-assign.all@ietf.org; > last-call@ietf.org > Subject: [Int-dir] Intdir last call review of draft-ietf-dhc-mac-assign-06 > > Reviewer: Tatuya Jinmei > Review result: Ready with Nits > > I am an assigned INT directorate reviewer for draft-ietf-dhc-mac-assign. > These comments were written primarily for the benefit of the Internet Area > Directors. Document editors and > shepherd(s) should treat these comments just like they would treat > comments from any other IETF contributors and resolve them along with any > other Last Call comments that have been received. For more details on the > INT Directorate, see https://datatracker.ietf.org/group/intdir/about/ . > > I've reviewed draft-ietf-dhc-mac-assign-06 (07 was submitted while I was > reviewing 06, and I also checked 07 on some specific points to see if it's > changed, but the check is not comprehensive so some comments may be already > moot or addressed.) I think this draft is basically ready. Its purpose > and protocol details are well written, and the protocol is generally a > straightforward application of the basic > DHCPv6 (IP) address assignment protocol as described in RFC8415. I didn't > find any obvious problem. > > My comments are largely editorial. The first one for Section 8 may need > some discussion, but I'd basically leave the authors whether/how to address > the comments including this one. > > Specific comments: > > - Section 1: > > The IEEE originally set aside half of the 48-bit MAC Address space > for local use (where the U/L bit is set to 1). In 2017, the IEEE > specified an optional specification (IEEE 802c) that divides this > space into quadrants (Standards Assigned Identifier, Extended Local > Identifier, Administratively Assigned Identifier, and a Reserved > quadrant) - more details are in Appendix A. > > I wonder whether this paragraph could refer to draft-ietf-dhc-slap-quadrant --0000000000005a725005a76799af Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Jinmei, Bernie,

Apologies for the be= lated e-mail. Thanks Jinmei for the review.

I agre= e with Bernie's responses, thanks for that.

Ca= rlos

On Wed, Jun 3, 2020 at 9:56 PM Bernie Volz (volz) <volz@cisco.com> wrote:
Hi Jinmei.

Thanks much for the review!

Comments below (BV>). Carlos may also have some.

As these are fairly minor, I will queue them up for a -08 as there may be m= ore discussion on these comments and/or IESG reviews may raise some additio= nal issues.

- Bernie

-----Original Message-----
From: Int-dir <int-dir-bounces@ietf.org> On Behalf Of Tatuya Jinmei via Datatr= acker
Sent: Wednesday, June 3, 2020 2:30 PM
To: int-dir@ietf.org<= /a>
Cc: dhcwg@ietf.org;= draft-ietf-dhc-mac-assign.all@ietf.org; last-call@ietf.org
Subject: [Int-dir] Intdir last call review of draft-ietf-dhc-mac-assign-06<= br>
Reviewer: Tatuya Jinmei
Review result: Ready with Nits

I am an assigned INT directorate reviewer for draft-ietf-dhc-mac-assign. Th= ese comments were written primarily for the benefit of the Internet Area Di= rectors. Document editors and
shepherd(s) should treat these comments just like they would treat comments= from any other IETF contributors and resolve them along with any other Las= t Call comments that have been received. For more details on the INT Direct= orate, see https://datatracker.ietf.org/group/intdir= /about/ .

I've reviewed draft-ietf-dhc-mac-assign-06 (07 was submitted while I wa= s reviewing 06, and I also checked 07 on some specific points to see if it&= #39;s changed, but the check is not comprehensive so some comments may be a= lready moot or addressed.)=C2=A0 I think this draft is basically ready.=C2= =A0 Its purpose and protocol details are well written, and the protocol is = generally a straightforward application of the basic
DHCPv6 (IP) address assignment protocol as described in RFC8415.=C2=A0 I di= dn't find any obvious problem.

My comments are largely editorial.=C2=A0 The first one for Section 8 may ne= ed some discussion, but I'd basically leave the authors whether/how to = address the comments including this one.

Specific comments:

- Section 1:

=C2=A0 =C2=A0The IEEE originally set aside half of the 48-bit MAC Address s= pace
=C2=A0 =C2=A0for local use (where the U/L bit is set to 1).=C2=A0 In 2017, = the IEEE
=C2=A0 =C2=A0specified an optional specification (IEEE 802c) that divides t= his
=C2=A0 =C2=A0space into quadrants (Standards Assigned Identifier, Extended = Local
=C2=A0 =C2=A0Identifier, Administratively Assigned Identifier, and a Reserv= ed
=C2=A0 =C2=A0quadrant) - more details are in Appendix A.

I wonder whether this paragraph could refer to draft-ietf-dhc-slap-quadrant=
--0000000000005a725005a76799af-- From nobody Sat Jun 6 05:12:07 2020 Return-Path: X-Original-To: int-dir@ietf.org Delivered-To: int-dir@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 6453F3A0860; Sat, 6 Jun 2020 05:11:58 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Ralf Weber via Datatracker To: Cc: last-call@ietf.org, draft-ietf-capport-rfc7710bis.all@ietf.org, captive-portals@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.1.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <159144551834.13294.561095521927993926@ietfa.amsl.com> Reply-To: Ralf Weber Date: Sat, 06 Jun 2020 05:11:58 -0700 Archived-At: Subject: [Int-dir] Intdir telechat review of draft-ietf-capport-rfc7710bis-07 X-BeenThere: int-dir@ietf.org X-Mailman-Version: 2.1.29 List-Id: "This list is for discussion between the members of the Internet Area directorate." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Jun 2020 12:11:59 -0000 Reviewer: Ralf Weber Review result: Ready with Nits Moin! I am an assigned INT directorate reviewer for draft-ietf-capport-rfc7710bis. These comments were written primarily for the benefit of the Internet Area Directors. Document editors and shepherd(s) should treat these comments just like they would treat comments from any other IETF contributors and resolve them along with any other Last Call comments that have been received. For more details on the INT Directorate, see https://datatracker.ietf.org/group/intdir/about/ This draft defines an update to RFC7710 on the different methods a network can use to signal an existence of a captive portal. The draft is well written and actually addressed one nit I had with RFC7710 when reading it for the first time for the review of the bis document. There are two things that I would consider doing differently, but they don't affect the overall draft. In section two of the draft you have: In all variants of this option, the URI MUST be that of the captive portal API endpoint, conforming to the recommendations for such URIs [draft-ietf-capport-api]. Now I read the latest draft-ietf-capport-api on datatracker and there were no formal or recommendations at all for URI schemes. There were examples, but I guess if you are implementing this and you are told that there are guidelines they should be clearly spelled out. Protocol wise it is important that they implement the API endpoint correct and the URI really doesn't matter to much, so I would end the sentence at the comma. In section 3 Precedence of API URI the first paragraph tells me as am implementer that I'm free to implement whatever to use of the three methods described in the draft, however the second paragraph tells me that I should log an error if they are different. That makes no sense for a lazy coder like me as I would not look into other methods if one has succeeded. I think it is ok to give that freedom implied by the first paragraph to implementors here, but to really give them freed we should scrap the second paragraph. If the authors feel they need to describe the client logic in more detail this has to be extended way beyond a single paragraph. So long -Ralf From nobody Mon Jun 8 10:51:34 2020 Return-Path: X-Original-To: int-dir@ietfa.amsl.com Delivered-To: int-dir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 75F833A0ED2 for ; Mon, 8 Jun 2020 10:51:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=juniper.net header.b=j+rRrSSW; dkim=pass (1024-bit key) header.d=juniper.net header.b=cKwLIH1L 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 hEY4xBYHHCwd for ; Mon, 8 Jun 2020 10:51:31 -0700 (PDT) Received: from mx0b-00273201.pphosted.com (mx0a-00273201.pphosted.com [208.84.65.16]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 17D843A0ED0 for ; Mon, 8 Jun 2020 10:51:30 -0700 (PDT) Received: from pps.filterd (m0108157.ppops.net [127.0.0.1]) by mx0a-00273201.pphosted.com (8.16.0.42/8.16.0.42) with SMTP id 058Hl1kC002678 for ; Mon, 8 Jun 2020 10:51:30 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; h=from : to : subject : date : message-id : content-type : mime-version; s=PPS1017; bh=pUF/lFYeXhe59H+0eue6w9vVlq7DuZUR3E3fOFo46No=; b=j+rRrSSWPSzIWAYjevQPoeFzyOfVkocozJeK5I0Wfu1DFaQbUSZ8T+yFVitO54wMtJS1 qylZ19azNBDc1t8weZZQQiiHQfN/O1ieJ8AdRw9NqAaejPWBXiEcCaMHmoxRfyILjgTt TnRg7U9Xw2CcXPK0rpZDHsCcj2e4h+VJQTMGPUVtJwvtjx4egUh/vjaPSyLXpH8Esu6m S9ypGmE6CF1icKpE5opigHkjEyULTA2LvI7EjJbMRVJ+8ZrjDXg7hshxuLjJHPzzLybF h+CLt8JcPHqKH5RixmTz3ii9CJlHhmpPDn1oJHisJAUANDPuO6z/ONAVs7hGyf/Coq69 2A== Received: from nam12-mw2-obe.outbound.protection.outlook.com (mail-mw2nam12lp2049.outbound.protection.outlook.com [104.47.66.49]) by mx0a-00273201.pphosted.com with ESMTP id 31gadn33tk-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for ; Mon, 08 Jun 2020 10:51:30 -0700 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=DZ/InM0WF9sVwzR0EnzRhswlQePK8fuay38/HIRCsbshmOmjQqy7nhx9v7T2u3md0ku5xINpmOhFsTb1o87KjSX6CVnARYnOxw/nl8HblWu0QLa4FR4egvKX2pkbwXSP+kLGaq2OD0wuOMZ14NSA7rlO9/z3B+i3lv86GjGCQaLSH4UBNOzC0I2SNMkM3G5LdujjJkTp2JK/0Dg2wuZWCJ/3y6LuY7DpbmTfE4TO+YU6PIuqoslwbCMixGE8t/R43lZOoG0jyVdCi06a7B1IZ9mrtokDRhICpktTdqVZSzhf4Sc6wyiYlS5pkZIEhIk1lKiQrmQ7PLYN/pqxPeEOmQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=pUF/lFYeXhe59H+0eue6w9vVlq7DuZUR3E3fOFo46No=; b=f3cwy3sWCOUSSkGOotvEKa4aPKa0TUeT/f8kXTDtektelkrpcnJWjm9p3pItymEPBJEs9TRfmNCqhCLhTfWTpG9cTK2uMh3cLKdqFLDT1fsYfiBRIXTubQmhEizoh3n+TjCJtr8fWe4pQqGf9sYKGpq3+ZfiC5gddhuadnAJuCiAO0ccgX5IjO4fvgvcVuCSWoGDp+5ohq43rDKR3hRXDAqpnjN5fGhMyFyXB5ZjvCiMMSWtdigddNaXEkUsNedgfT++1XRp4AjDMa5TiRQX8MxHrQyygAxnxB0yYaEjxGuSuN/xnNC/2hugBBWloLFT/hurx4fMaZEig9DLciiazw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=juniper.net; dmarc=pass action=none header.from=juniper.net; dkim=pass header.d=juniper.net; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=pUF/lFYeXhe59H+0eue6w9vVlq7DuZUR3E3fOFo46No=; b=cKwLIH1LIdJPVEm0tHd/dflMGl2T3QccKjEHERonDo2a1YI6SmOOCFPF9DCgoX7sP5CWptepAJsvXYuK7GCcuqdc36jL4fU65ldsU/ng2cI76XB6ykqpudrCgosG+I3wLA9NqRqhNJL07/UyL4pJbxYSxMRSdSNjnxLnU5Zhhhc= Received: from DM6PR05MB6348.namprd05.prod.outlook.com (2603:10b6:5:122::15) by DM6PR05MB5484.namprd05.prod.outlook.com (2603:10b6:5:56::32) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3088.12; Mon, 8 Jun 2020 17:51:27 +0000 Received: from DM6PR05MB6348.namprd05.prod.outlook.com ([fe80::9d38:2336:1379:ce2e]) by DM6PR05MB6348.namprd05.prod.outlook.com ([fe80::9d38:2336:1379:ce2e%7]) with mapi id 15.20.3088.017; Mon, 8 Jun 2020 17:51:27 +0000 From: Ron Bonica To: "int-dir@ietf.org" Thread-Topic: Intdir review of draft-ietf-capport-architecture Thread-Index: AdY9vWyOU12b0u4BTCSGmikJ2mWEjQ== Date: Mon, 8 Jun 2020 17:51:27 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: msip_labels: MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_Enabled=true; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_SetDate=2020-06-08T17:51:24Z; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_Method=Standard; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_Name=0633b888-ae0d-4341-a75f-06e04137d755; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_SiteId=bea78b3c-4cdb-4130-854a-1d193232e5f4; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_ActionId=aeaf8439-7702-4bd4-af77-83e7c525e11c; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_ContentBits=2 dlp-product: dlpe-windows dlp-version: 11.5.0.60 dlp-reaction: no-action authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=juniper.net; x-originating-ip: [108.28.233.91] x-ms-publictraffictype: Email x-ms-office365-filtering-ht: Tenant x-ms-office365-filtering-correlation-id: 69b7e9a5-212e-49cf-2e96-08d80bd49162 x-ms-traffictypediagnostic: DM6PR05MB5484: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:8882; x-forefront-prvs: 042857DBB5 x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: vwZS2BGV8VPCqLFhnpIq/WZ7voKlZcprtSkQibLTCnDrFv9XTLcD1D8tesfZBkjD46YZszCvxIyr3pIpGM7/ZrAbjpv5eUUOUYHna9h3GNvm8/mf8n6suU5pf+gWe355oxfT4kfA3PKTB+tFuowjeeKSxNZjrs6snYVawX45iokIJ23hepdXCWBLHB67gvE6Q1kmW/7o2wwPSALve3mUsndSu9N6sHYq6lGzPEBL/kAFybjDWnCGBv0M6mNvnptfFL+geoUru6xHmBvXDhtiuVLa/+vhL4AKMD7nGkF/sNpE6V2lfBpOXLjrFyqX49LobTcytMdf3mmIVyHFspQCI/4beSbFEFUCcW8NUg2pfy/JKFBcKGgw+hPC9alsqYg257ndh/j1GI7HNcAWd/2tVA== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DM6PR05MB6348.namprd05.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(366004)(39860400002)(136003)(346002)(376002)(396003)(66556008)(52536014)(66446008)(26005)(186003)(64756008)(6916009)(76116006)(66476007)(66574014)(4744005)(478600001)(316002)(66946007)(966005)(9686003)(55016002)(5660300002)(33656002)(6506007)(8676002)(86362001)(8936002)(2906002)(7696005)(71200400001); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata: s8kQ42JVQMYTUWQv+IrwxWklINGV6gAyGBjHWQ6kp5ZJ9dG9uDIjbKaXZeLx1lNpPphaZEEAJ2Fm7uh2yvGY54fbtWjnXV5AbYUfpb8FCk1uGuAkOpD6AGHHDVQFocfUfnU3Tj8au5gqep88RAvZvh9n549AbBTI6hkQWxu52JUDOE2UFFt93Vjxn98Lm8SpiKaEtk0jFycxgtKOoetOsKMrwojqp+T/66JNY5j2GkiO6j5fawbLxxeOLzH+yel7XFE8MNQVXUxQoZfOSYrDiW05O55bfWxAmVMYiMGQpmuBvReSjMLsnoB/2uuYGCp8MzFYjqwuPNgcyUZsLvjNx1Cc9zLySREHC5PK4fI1RcWMLJGrBuLSC8GqWU79QXfmkmtzB5evOpDmu6oz0xKOJh0czsf+IR5bhLVHEUISCp7CLdGTTCtJvkF5SqYcExpYz7KwQPGXDG12S6FZUKjf6THLwNBW9Zf2ihOKstHZHjifilb3xmsqXpIM+YzOAR/D x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_DM6PR05MB63487FDEAD470782AFDED926AE850DM6PR05MB6348namp_" MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-Network-Message-Id: 69b7e9a5-212e-49cf-2e96-08d80bd49162 X-MS-Exchange-CrossTenant-originalarrivaltime: 08 Jun 2020 17:51:27.1918 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: DFV7xB8F0dBjZKY1lInMJCUDnobtivh6kzdLmB4pleE+6wUHKukWdv6wpcm4pTZ7zpSJNzepkzWQCeiW+7Vdhg== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR05MB5484 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.216, 18.0.687 definitions=2020-06-08_17:2020-06-08, 2020-06-08 signatures=0 X-Proofpoint-Spam-Details: rule=outbound_spam_notspam policy=outbound_spam score=0 bulkscore=0 mlxlogscore=745 spamscore=0 impostorscore=0 clxscore=1011 priorityscore=1501 adultscore=0 malwarescore=0 phishscore=0 cotscore=-2147483648 suspectscore=0 lowpriorityscore=0 mlxscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2004280000 definitions=main-2006080126 Archived-At: Subject: [Int-dir] Intdir review of draft-ietf-capport-architecture X-BeenThere: int-dir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This list is for discussion between the members of the Internet Area directorate." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Jun 2020 17:51:33 -0000 --_000_DM6PR05MB63487FDEAD470782AFDED926AE850DM6PR05MB6348namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Folks, I am an assigned INT directorate reviewer for draft-ietf-capport-architectu= re. These comments were written primarily for the benefit of the Internet A= rea Directors. Document editors and shepherd(s) should treat these comments= just like they would treat comments from any other IETF contributors and r= esolve them along with any other Last Call comments that have been received= . For more details on the INT Directorate, see https://datatracker.ietf.org= /group/intdir/about/ . Based on my review, the document IS ready to go to IETF Last Call and there= fore CAN be forwarded to the IESG Based on my review, if I was on the IESG I would ballot this document as NO= OBJECTION. Ron Bonica Juniper Business Use Only --_000_DM6PR05MB63487FDEAD470782AFDED926AE850DM6PR05MB6348namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Folks,

 

I am an assigned INT directorate reviewer for draft-= ietf-capport-architecture. These comments were written primarily for the be= nefit of the Internet Area Directors. Document editors and shepherd(s) shou= ld treat these comments just like they would treat comments from any other IETF contributors and resolve the= m along with any other Last Call comments that have been received. For more= details on the INT Directorate, see https://datatracker.ietf.org/group/int= dir/about/ <https://datatracker.ietf.org/group/intdir/about/>.

 

Based on my review, the document IS ready to go to I= ETF Last Call and therefore CAN be forwarded to the IESG

 

Based on my review, if I was on the IESG I would bal= lot this document as NO OBJECTION.

 

        &nbs= p;            &= nbsp;           &nbs= p;            Ron Bo= nica


Juniper Business= Use Only

--_000_DM6PR05MB63487FDEAD470782AFDED926AE850DM6PR05MB6348namp_--