Skip to main content

Structured Local Address Plan (SLAP) Quadrant Selection Option for DHCPv6
draft-ietf-dhc-slap-quadrant-12

Revision differences

Document history

Date Rev. By Action
2020-11-18
12 (System) RFC Editor state changed to AUTH48-DONE from AUTH48
2020-11-09
12 (System) RFC Editor state changed to AUTH48 from RFC-EDITOR
2020-10-26
12 (System) RFC Editor state changed to RFC-EDITOR from EDIT
2020-10-19
12 (System) RFC Editor state changed to EDIT from REF
2020-10-19
12 (System) RFC Editor state changed to REF from EDIT
2020-10-16
12 (System) IANA Action state changed to RFC-Ed-Ack from Waiting on RFC Editor
2020-10-15
12 (System) IANA Action state changed to Waiting on RFC Editor from In Progress
2020-10-15
12 (System) IANA Action state changed to In Progress from Waiting on Authors
2020-10-15
12 (System) IANA Action state changed to Waiting on Authors from In Progress
2020-10-13
12 (System) RFC Editor state changed to EDIT
2020-10-13
12 (System) IESG state changed to RFC Ed Queue from Approved-announcement sent
2020-10-13
12 (System) Announcement was received by RFC Editor
2020-10-13
12 (System) IANA Action state changed to In Progress
2020-10-13
12 Amy Vezza IESG state changed to Approved-announcement sent from Approved-announcement to be sent
2020-10-13
12 Amy Vezza IESG has approved the document
2020-10-13
12 Amy Vezza Closed "Approve" ballot
2020-10-13
12 Amy Vezza Ballot approval text was generated
2020-10-13
12 Amy Vezza Ballot writeup was changed
2020-10-13
12 Amy Vezza IESG state changed to Approved-announcement to be sent from IESG Evaluation::AD Followup
2020-10-13
12 Carlos Jesús Bernardos New version available: draft-ietf-dhc-slap-quadrant-12.txt
2020-10-13
12 (System) New version accepted (logged-in submitter: Carlos Bernardos)
2020-10-13
12 Carlos Jesús Bernardos Uploaded new revision
2020-10-12
11 Robert Wilton
[Ballot comment]
Discuss cleared.  The document has been reviewed by some members of IEEE, and appropriate mark ups have been made.

Thank you for your …
[Ballot comment]
Discuss cleared.  The document has been reviewed by some members of IEEE, and appropriate mark ups have been made.

Thank you for your perseverance to see this one through.

Rob


Previous discuss comment:

Disclaimer: I'm not familiar with IEEE 802.1CQ, nor am I a DHCPv6 expert ...  Some of these questions/comments may have been answered there.

My first question relates to process:  Have members of the IEEE 802.1WG had an opportunity to review and provide input into this document?  If not, then I think that it would be good for them to be given the opportunity to do so.  In particular, they might question whether it is appropriate for a client to be able to request MAC addresses to be assigned from the SAI or "reserved for future use" address pools.  It is worth noting that there is an IETF-IEEE liaison meeting on Mon 15th, that may help.

I'm not sure that I really like how the algorithm is defined in this document (relative to draft-ietf-dhc-mac-assign).  In draft-ietf-dhc-mac-assign, the client makes a request, and the server can respond with a completely different smaller MAC address range, i.e. the client is just providing hints/suggestions to the server.  I would be much happier if the QUAD option specified in this document behaved similarly.  I.e. the QUAD option is used by a client to specify an ordered preference of quads to use, but otherwise the server is allow to offer up an address, or block of addresses, outside the preferred quads, which the client could choose to not accept, or release.

Previous non blocking comments.

1. Introduction

  o  Quadrant "Administratively Assigned Identifier" (AAI) MAC
      addresses are assigned locally by an administrator.  Multicast
      IPv6 packets use a destination address starting in 33-33 and this
      falls within this space and therefore should not be used to avoid
      conflict with the MAC addresses used for use with IPv6 multicast
      addresses.  For 48-bit MAC addresses, 44 bits are available.

Multicast IPv6 packets shouldn't be a problem for the AAI range, on the assumption that only unicast MAC addresses get assigned.  Hence, probably the text related to Multicast IPv6 addresses can be deleted.

3.  Quadrant Selection Mechanisms examples

I see that this text as not being normative, and is potentially somewhat repeating what has been stated in the introduction.  I think that this text might be better moved to an appendix.

4.  DHCPv6 Extensions

The algorithmic description in this document seems to heavily overlap with the algorithm described in draft-ietf-dhc-mac-assign, with a fair amount of repetitive descriptive text of the algorithm.  I believe that it would be better if this option was written as a modification of the procedure defined in draft-ietf-dhc-mac-assign (particularly, if the algorithm is simplified as a I propose in my discuss).
2020-10-12
11 Robert Wilton [Ballot Position Update] Position for Robert Wilton has been changed to No Objection from Discuss
2020-09-30
11 Carlos Jesús Bernardos New version available: draft-ietf-dhc-slap-quadrant-11.txt
2020-09-30
11 (System) New version accepted (logged-in submitter: Carlos Bernardos)
2020-09-30
11 Carlos Jesús Bernardos Uploaded new revision
2020-08-03
10 (System) Sub state has been changed to AD Followup from Revised ID Needed
2020-08-03
10 (System) IANA Review state changed to Version Changed - Review Needed from IANA OK - Actions Needed
2020-08-03
10 Carlos Jesús Bernardos New version available: draft-ietf-dhc-slap-quadrant-10.txt
2020-08-03
10 (System) New version approved
2020-08-03
10 (System) Request for posting confirmation emailed to previous authors: Alain Mourad , Carlos Bernardos
2020-08-03
10 Carlos Jesús Bernardos Uploaded new revision
2020-06-11
09 Cindy Morgan IESG state changed to IESG Evaluation::Revised I-D Needed from IESG Evaluation
2020-06-11
09 Magnus Westerlund [Ballot Position Update] New position, No Objection, has been recorded for Magnus Westerlund
2020-06-11
09 Erik Kline [Ballot Position Update] New position, No Objection, has been recorded for Erik Kline
2020-06-10
09 Roman Danyliw [Ballot Position Update] New position, No Objection, has been recorded for Roman Danyliw
2020-06-10
09 Deborah Brungard [Ballot Position Update] New position, No Objection, has been recorded for Deborah Brungard
2020-06-10
09 Murray Kucherawy
[Ballot comment]
As with Robert, I'm interested to hear what coordination with IEEE has occurred, both for this and for the companion "mac-assign" document.

I'm …
[Ballot comment]
As with Robert, I'm interested to hear what coordination with IEEE has occurred, both for this and for the companion "mac-assign" document.

I'm also, as Warren, puzzled as to why the Shepherd Writeup claims there's no IPR claim when the datatracker disagrees, and struck by how much text here overlaps with the "mac-assign" document.

As for editorial remarks, I have some:

Section 1:
* I am unable to parse the bullet that defines the "Administratively Assigned Identifier" quadrant.

Section 1.1.1:
* "Examples of this include: sensors ..." -- remove the colon
* "... temporary MAC address, to send initial ..." -- remove the comma
* "... good for assigning addresses from, but ..." -- remove "from"
* "... easy to track users' movement." -- s/movement/movements/
* "... best SLAP quadrant to assign addresses from, ..." -- suggest "best SLAP quadrant from which to assign addresses, ..."

Section 2:
* Although I realize this section is explicit about where "IA_LL" and "LLADDR" are formally defined, it might be nice to provide their full prose names on first use.
* "... typically 6 bytes long ..." -- s/6/six/

Section 3:
* "If we now take the ..." -- suggest "Next, consider the ..."
* Generally I found this section to have a mushy sort of structure.  It begins and ends by mapping certain use cases onto certain quadrants explicitly, but in the middle seems to wander into a checklist of things you might think about without mapping those concepts toward a preferred quadrants.  You might consider firming this up with, perhaps four separate paragraphs, or even subsections, each describing ideal uses for one of the quadrants, taking into account the facets of that choice you've enumerated here.

Section 6
* I suggest omitting the IANA URL.  What if it were to change?  All you really need is the registry name.
2020-06-10
09 Murray Kucherawy Ballot comment text updated for Murray Kucherawy
2020-06-10
09 Murray Kucherawy [Ballot Position Update] Position for Murray Kucherawy has been changed to No Objection from No Record
2020-06-10
09 Murray Kucherawy
[Ballot comment]
As with Robert, I'm interested to hear what coordination with IEEE has occurred, both for this and for the companion "mac-assign" document.

I'm …
[Ballot comment]
As with Robert, I'm interested to hear what coordination with IEEE has occurred, both for this and for the companion "mac-assign" document.

I'm also, as Warren, puzzled as to why the Shepherd Writeup claims there's no IPR claim when the datatracker disagrees, and struck by how much text here overlaps with the "mac-assign" document.

As for editorial remarks, I have some:

Section 1:
* I am unable to parse the bullet that defines the "Administratively Assigned Identifier" quadrant.

Section 1.1.1:
* "Examples of this include: sensors ..." -- remove the colon
* "... temporary MAC address, to send initial ..." -- remove the comma
* "... good for assigning addresses from, but ..." -- remove "from"
* "... easy to track users' movement." -- s/movement/movements/
* "... best SLAP quadrant to assign addresses from, ..." -- suggest "best SLAP quadrant from which to assign addresses, ..."

Section 2:
* "... typically 6 bytes long ..." -- s/6/six/

Section 3:
* "If we now take the ..." -- suggest "Next, consider the ..."
* Generally I found this section to have a mushy sort of structure.  It begins and ends by mapping certain use cases onto certain quadrants explicitly, but in the middle seems to wander into a checklist of things you might think about without mapping those concepts toward a preferred quadrants.  You might consider firming this up with, perhaps four separate paragraphs, or even subsections, each describing ideal uses for one of the quadrants, taking into account the facets of that choice you've enumerated here.

Section 6
* I suggest omitting the IANA URL.  What if it were to change?  All you really need is the registry name.
2020-06-10
09 Murray Kucherawy Ballot comment text updated for Murray Kucherawy
2020-06-09
09 Alvaro Retana [Ballot comment]
I support Rob's DISCUSS.

IEEEStd802c-2017 should be a Normative reference.
2020-06-09
09 Alvaro Retana [Ballot Position Update] New position, No Objection, has been recorded for Alvaro Retana
2020-06-08
09 Barry Leiba
[Ballot comment]
— Abstract —

  The IEEE is working on mechanisms to allocate addresses in the one of
  these quadrants (IEEE 802.1CQ).

Nit: …
[Ballot comment]
— Abstract —

  The IEEE is working on mechanisms to allocate addresses in the one of
  these quadrants (IEEE 802.1CQ).

Nit: change “in the one of” to “in one of”.

  given client out of the quadrant requested by relay or client.

Nit: make it “by the relay or client.”

— Section 1 —

      Multicast
      IPv6 packets use a destination address starting in 33-33 and this
      falls within this space and therefore should not be used to avoid
      conflict with the MAC addresses used for use with IPv6 multicast
      addresses.

There are multiple problems with this sentence, starting with its being too long.  I suggest this (but please correct this if I got it wrong):

NEW
      Multicast
      IPv6 packets use a destination address starting with 33-33, which
      falls within the AAI quadrant.  Those addresses should not be used,
      in order to avoid conflict with the MAC addresses used for IPv6
      multicast.
END

  o  Quadrant "Reserved for future use" where MAC addresses may be

Nit: remove “where”.

— Section 1.1 —

  allocates the MAC address to the given client out of the quadrant
  requested by relay or client.

Nit: make it “by the relay or client.”

— Section 3 —

  o  Type of IoT deployment: e.g., industrial, domestic, rural, etc.
      For small deployments, such as domestic ones, the IoT itself can

Twice in this paragraph you say “the IoT”, when I think you mean “the IoT device”.

  IoT devices are typically very resource constrained, so
  there may only be simple decision making process

Make it “be a simple decision-making process”

  If we now take the WiFi device scenario, considering for example that
  a laptop or smartphone connects to a network using its built in MAC
  address.

This is not a complete sentence; please make it one.

  Besides,
  changing the SLAP quadrant used might also be used as an additional
  enhancement to make it harder to track the user location.

This is awkward, “used might also be used”.  I suggest, “...changing the SLAP quadrant might also...”.

  SLAP quadrant using information provided by the cloud management
  system (CMS) or virtualization infrastructure manager (VIM) running

Neither abbreviation is used elsewhere in this document, so I suggest removing both “(CMS)” and “(VIM)”.

      as some quadrants are
      better suited (e.g., ELI/SAI) for supporting migration in a large

The parenthetical is misplaced and interrupts the sentence flow.

NEW
      as some quadrants (ELI and SAI) are
      better suited for supporting migration in a large
END

or, better still:

NEW
      as the ELI and SAI quadrants are
      better suited for supporting migration in a large
END

  o  VM connectivity characteristics , e.g.,: standalone, part of a

Nit: punctuation around “e.g.” is wrong:

NEW
  o  VM connectivity characteristics, e.g., standalone, part of a
END

— Section 4.1 —

      The client SHOULD NOT pick a server that does not
      advertise an address in the requested quadrant.

This SHOULD NOT doesn’t make sense to me.  Why would it?  What would be an informed reason to pick one that doesn’t have what it wants?  Is there a reason not to just say, “The client will pick a server that advertises an address in the quadrant the client requested,” without using BCP 14 key words?
2020-06-08
09 Barry Leiba [Ballot Position Update] New position, No Objection, has been recorded for Barry Leiba
2020-06-08
09 Sabrina Tanamal IANA Review state changed to IANA OK - Actions Needed from Version Changed - Review Needed
2020-06-08
09 Sabrina Tanamal IANA Experts State changed to Expert Reviews OK from Reviews assigned
2020-06-08
09 Benjamin Kaduk
[Ballot comment]
I had a little bit of a hard time understanding how all the given
examples benefit from using a specific quadrant for their …
[Ballot comment]
I had a little bit of a hard time understanding how all the given
examples benefit from using a specific quadrant for their allocations,
but that may just be my lack of background, and in any case is not a
reason to hold up the document.

Section 1.1.1

  o  IoT (Internet of Things): where there are a lot of cheap,
      sometimes short lived and disposable devices.  Examples of this
      include: sensors and actuators for health or home automation
      applications.  In this scenario, it is common that upon a first
      boot, the device uses a temporary MAC address, to send initial
      DHCP packets to available DHCP servers.  IoT devices typically
      request a single MAC address for each available network interface.

I'm a bit confused by the use of present tense here ("it is common"),
given that AFAIK the companion document draft-ietf-dhc-mac-assign is the
first mechanism for DHCP-based MAC address assignment.

      temporary MAC address.  This type of device is typically not
      moving.  In general, any type of SLAP quadrant would be good for
      assigning addresses from, but ELI/SAI quadrants might be more
      suitable in some scenarios, such as if the addresses need to
      belong to the CID assigned to the IoT communication device vendor.

side note: I'm curious what kind of case would require that the address
belong to the CID of the device's vendor.

Section 2

Interesting that we say that client+server support IA_LL and LLADDR but
nothing about QUAD :)

Section 3

  change address several times).  This information includes, but it is
  not limited to:

  o  Type of network the device is connected: public, work, home.

  o  Trusted network?  Y/N.
  [...]

nit: it might be nice to use a parallel structure for all of the bullet
points ('?' vs ':', prose discussion vs short answer, etc.)

  o  Mobility?  Y/N.

A few more words about what sense "mobility" is used in might be in
order.

  quadrants.  If the device is not moving and attached to a trusted
  network (e.g. at work), then it is probably best to select the ELI

side note: it's not entirely clear that "at work" implies "not moving"
-- in some environments it's common to move between desk and conference
room, potentially on a different floor or in a different building.

  Last, if we consider the data center scenario, a hypervisor might
  request local MAC addresses to be assigned to virtual machines.  As
  in the previous scenarios, the hypervisor might select the preferred
  SLAP quadrant using information provided by the cloud management
  system (CMS) or virtualization infrastructure manager (VIM) running
  on top of the hypervisor.  This information might include, but is not
  limited to:

As was (IIRC) noted by a directorate reviewer, we don't use "CMS" or
"VIM" again, and since at least "CMS" collides with another well-known
IETF acronym, there seems to be little or negative value in including
the acronyms here.

Section 4.1

I suggest using "IA_LL(LLADDR,QUAD)" in step 1 of Figure 3, as is done
for the other lines, to match the prose text's MUST-level requirement to
include LLADDR.

      option.  In order to indicate the preferred SLAP quadrant(s), the
      IA_LL option includes the new OPTION_SLAP_QUAD option in the
      IA_LL-option field (with the LLAADR option).

Even though QUAD does not give provision for nested options, it would
perhaps be better to use "alongside" or "as a sibling of" or similar,
rather than "with", to describe the relationship between QUAD and
LLADDR.
Also, nit: s/LLAADR/LLADDR/.

      an LLADDR option that specifies the addresses being offered.  If
      the server supports the new QUAD IA_LL-option, and manages a
      block of addresses belonging to the requested quadrant(s), the
      addresses being offered MUST belong to the requested quadrant(s).

nit: I don't expect a single block of addresses to span quadrant
boundaries, so perhaps "belonging to a requested quadrant" and "MUST
belong to a requested quadrant" would be more appropriate.

  3.  The client waits for available servers to send Advertise
      responses and picks one server as defined in Section 18.2.9 of
      [RFC8415].  The client SHOULD NOT pick a server that does not
      advertise an address in the requested quadrant.  The client then

Perhaps "quadrant(s)" or "a requested quadrant", to match the previous
discussion?

      sends a Request message that includes the IA_LL container option
      with the LLADDR option copied from the Advertise message sent by
      the chosen server.  It includes the preferred SLAP quadrant(s) in
      the new QUAD IA_LL-option.

nit: I think s/the new/a new/ is better, since we have not discussed a
new QUAD option in the Request yet.

  The client SHOULD check if the received MAC address comes from one of
  the requested quadrants.  Otherwise, the client SHOULD NOT configure
  the obtained address.  It MAY repeat the process selecting a
  different DHCP server.

"repeat the process" sounds like sending the same Renew to a different
server, that is, different from the server that assigned the address
whose renewal is being requested.  Is that expected to be effective
(either in renewing the current assignment or in getting a new
allocation in a Reply, as opposed to an "I don't know about that" error
response)?

Section 4.2

side note: It's interesting to me that QUAD is not included in a
Relay-reply(Advertise()) but is included in a regular Advertise() when
no proxy is involved.  (Likewise for wrapped Reply().)

        payload.  Depending on the server's policy, the instance(s) of
        the option to process is selected.  For each of the entries in

Just to check: this is intended to allow both "use only one, and if both
are present which to use is up to local policy" and "apply the
intersection of both requests [with some local policy for which priority
to respect]"?  I note that later on we have some text that makes it
RECOMMENDED to prefer the client's, in a discussion that does not cover
the "intersection" option at all.  So perhaps the "intersection" option
is not intended to be available?

        in a Relay-reply message.  If the server supports the semantics
        of the preferred quadrant included in the QUAD option, and
        manages a block of addresses belonging to the requested
        quadrant(s), then the addresses being offered MUST belong to the
        requested quadrant(s).  The server SHOULD apply the contents of

[same nit as for §4.1]

  10.  This message is forwarded by the Relay in a Relay-forward
        message, including a QUAD IA_LL-option with the preferred
        quadrant.

I would consider repeating the mention from above about how the QUAD is
included here in case the server has to make a new assignment, to make
sure that the client (well, proxy's) preference is available in such
cases.

Section 5.1

  quadrant-n      Identifier of the quadrant (0: AAI, 1: ELI, 2:
                  Reserved, 3: SAI).  Each quadrant MUST only appear
                  once at most in the option.  A 1-byte field.

Perhaps note that this is Reserved in the sense of the IEEE quadrant,
not the usual IETF/IANA "reserved" usage?

  assigned preference).  Note that a quadrant - preference tuple is

nit: earlier we spell this a "(quadrant, preference) pair".  Using
consistent notation/terminology seems advisable.

  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.

side note: it's not 100% clear to me that we need to exclude the "no
preference among all four quadrants" case, though I certainly am not
insisting that we include it.

  specified quadrants, it SHOULD proceed with the assignment.  If the
  server cannot provide an assignment from one of the specified
  quadrant-n fields, it MUST NOT assign any addresses and return a
  status of NoQuadAvail (IANA-2) in the IA_LL Option.

This text seems to lose some of the subtlety around NoQuadAvail vs.
NoAddrsAvail that is prsent in Section 4.1.  It would be good to be
consistent about how we discuss these cases.

Section 7

Do I understand correctly that there is no technical mechanism to
prevent a relay from inserting a QUAD option inside what is nominally
the client's IA_LL, as opposed to as a top-level option in Relay-forward
(which is what it's "supposed to" do)?  We should probably say something
about how the proxy has to be trusted to do the right thing and a
malicious proxy could change/override the client's preference.

I'm surprised that RFC 7227 is not referenced here.

Though it is not referenced (yet?), RFC 7227 says that authors of
documents defining new DHCP options are "strongly advised to explicitly
define validation measures" for recipients of such options.  I do not
see much discussion of validation measures in this document (despite
there being MUST-level requirements on the quadrant-n fields with
respect to each other), just a mention that "first occurrance wins",
which is not exactly a validation step but more of a processing one; why
is there no need to provide more detailed validation measures?

Section 8

  The work in this draft will be further developed and explored under
  the framework of the H2020 5Growth (Grant 856709) and 5G-DIVE
  projects (Grant 859881).

I'm not 100% sure that we need to speculate about the future here
(especially given that it would become stale as time passes); would it
suffice to say that "this work is supported by" the grants in question?

Section 9.1

It's not entirely clear to me that we reference RFC 8200 in a normative
fashion.
2020-06-08
09 Benjamin Kaduk [Ballot Position Update] New position, No Objection, has been recorded for Benjamin Kaduk
2020-06-08
09 Robert Wilton
[Ballot discuss]
Hi,

Thanks for writing this document.  I have a few points that I believe are worthy of discussion.

Disclaimer: I'm not familiar with …
[Ballot discuss]
Hi,

Thanks for writing this document.  I have a few points that I believe are worthy of discussion.

Disclaimer: I'm not familiar with IEEE 802.1CQ, nor am I a DHCPv6 expert ...  Some of these questions/comments may have been answered there.

My first question relates to process:  Have members of the IEEE 802.1WG had an opportunity to review and provide input into this document?  If not, then I think that it would be good for them to be given the opportunity to do so.  In particular, they might question whether it is appropriate for a client to be able to request MAC addresses to be assigned from the SAI or "reserved for future use" address pools.  It is worth noting that there is an IETF-IEEE liaison meeting on Mon 15th, that may help.

I'm not sure that I really like how the algorithm is defined in this document (relative to draft-ietf-dhc-mac-assign).  In draft-ietf-dhc-mac-assign, the client makes a request, and the server can respond with a completely different smaller MAC address range, i.e. the client is just providing hints/suggestions to the server.  I would be much happier if the QUAD option specified in this document behaved similarly.  I.e. the QUAD option is used by a client to specify an ordered preference of quads to use, but otherwise the server is allow to offer up an address, or block of addresses, outside the preferred quads, which the client could choose to not accept, or release.
2020-06-08
09 Robert Wilton
[Ballot comment]
1. Introduction

  o  Quadrant "Administratively Assigned Identifier" (AAI) MAC
      addresses are assigned locally by an administrator.  Multicast
    …
[Ballot comment]
1. Introduction

  o  Quadrant "Administratively Assigned Identifier" (AAI) MAC
      addresses are assigned locally by an administrator.  Multicast
      IPv6 packets use a destination address starting in 33-33 and this
      falls within this space and therefore should not be used to avoid
      conflict with the MAC addresses used for use with IPv6 multicast
      addresses.  For 48-bit MAC addresses, 44 bits are available.

Multicast IPv6 packets shouldn't be a problem for the AAI range, on the assumption that only unicast MAC addresses get assigned.  Hence, probably the text related to Multicast IPv6 addresses can be deleted.

3.  Quadrant Selection Mechanisms examples

I see that this text as not being normative, and is potentially somewhat repeating what has been stated in the introduction.  I think that this text might be better moved to an appendix.

4.  DHCPv6 Extensions

The algorithmic description in this document seems to heavily overlap with the algorithm described in draft-ietf-dhc-mac-assign, with a fair amount of repetitive descriptive text of the algorithm.  I believe that it would be better if this option was written as a modification of the procedure defined in draft-ietf-dhc-mac-assign (particularly, if the algorithm is simplified as a I propose in my discuss).
2020-06-08
09 Robert Wilton [Ballot Position Update] New position, Discuss, has been recorded for Robert Wilton
2020-06-07
09 Éric Vyncke
[Ballot comment]
Thank you for this short document.

Please address all comments from the INT directorate review by Jinmei: https://datatracker.ietf.org/doc/review-ietf-dhc-slap-quadrant-08-intdir-lc-jinmei-2020-05-18/

as well as the IoT …
[Ballot comment]
Thank you for this short document.

Please address all comments from the INT directorate review by Jinmei: https://datatracker.ietf.org/doc/review-ietf-dhc-slap-quadrant-08-intdir-lc-jinmei-2020-05-18/

as well as the IoT directorate review by Jaime Jimenez:
https://datatracker.ietf.org/doc/review-ietf-dhc-slap-quadrant-07-iotdir-lc-jimenez-2020-06-04/

Regards

-éric
2020-06-07
09 Éric Vyncke Ballot comment text updated for Éric Vyncke
2020-06-04
09 Jaime Jimenez Request for Last Call review by IOTDIR Completed: Ready with Nits. Reviewer: Jaime Jimenez. Sent review to list.
2020-06-01
09 Warren Kumari
[Ballot comment]
I have one substantive / process question — the Shepherd writeup says that no IPR disclosures exist, but there does seem to be …
[Ballot comment]
I have one substantive / process question — the Shepherd writeup says that no IPR disclosures exist, but there does seem to be one — I wanted to make sure that this had been noted / process had been followed...

Otherwise, seems good - I must admit I don’t like the fact that there is so much repeated text with the MAC assign document, and that it isn’t clearer that MACs only really have to be unique per segment, but those are just prefernces / opinions...

Thank you for writing this,
W
2020-06-01
09 Warren Kumari [Ballot Position Update] New position, No Objection, has been recorded for Warren Kumari
2020-05-27
09 Ines Robles Request for Last Call review by GENART Completed: Ready with Issues. Reviewer: Ines Robles. Review has been revised by Ines Robles.
2020-05-27
09 Ines Robles Request for Last Call review by GENART Completed: Ready with Issues. Reviewer: Ines Robles. Sent review to list.
2020-05-27
09 (System) IANA Review state changed to Version Changed - Review Needed from IANA - Not OK
2020-05-27
09 Carlos Jesús Bernardos New version available: draft-ietf-dhc-slap-quadrant-09.txt
2020-05-27
09 (System) New version approved
2020-05-27
09 (System) Request for posting confirmation emailed to previous authors: Alain Mourad , Carlos Bernardos
2020-05-27
09 Carlos Jesús Bernardos Uploaded new revision
2020-05-27
08 Éric Vyncke Placed on agenda for telechat - 2020-06-11
2020-05-27
08 Éric Vyncke IESG state changed to IESG Evaluation from Waiting for Writeup
2020-05-27
08 Éric Vyncke [Ballot comment]
Thank you for this short document.

Please address all comments from the INT directorate review by Jinmei: https://datatracker.ietf.org/doc/review-ietf-dhc-slap-quadrant-08-intdir-lc-jinmei-2020-05-18/

Regards

-éric
2020-05-27
08 Éric Vyncke Ballot comment text updated for Éric Vyncke
2020-05-27
08 Éric Vyncke Ballot has been issued
2020-05-27
08 Éric Vyncke [Ballot Position Update] New position, Yes, has been recorded for Éric Vyncke
2020-05-27
08 Éric Vyncke Created "Approve" ballot
2020-05-27
08 Éric Vyncke Ballot writeup was changed
2020-05-27
08 (System) IESG state changed to Waiting for Writeup from In Last Call
2020-05-26
08 Sabrina Tanamal IANA Experts State changed to Reviews assigned
2020-05-26
08 (System) IANA Review state changed to IANA - Not OK from IANA - Review Needed
2020-05-26
08 Sabrina Tanamal
(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

The IANA Functions Operator has completed its review of draft-ietf-dhc-slap-quadrant-08. If any part of this review is inaccurate, please let …
(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

The IANA Functions Operator has completed its review of draft-ietf-dhc-slap-quadrant-08. If any part of this review is inaccurate, please let us know.

The IANA Functions Operator understands that, upon approval of this document, there are two actions which we must complete.

First, in the Option Code registry on the Dynamic Host Configuration Protocol for IPv6 (DHCPv6) registry page located at:

https://www.iana.org/assignments/dhcpv6-parameters/

a single, new registration is to be made as follows:

Value: [ TBD-at-Registration ]
Description: OPTION_SLAP_QUAD
Client ORO: No
Singleton Option: No
Reference: [ RFC-to-be ]

As this document requests registrations in an Expert Review (see RFC 8126) registry, we will initiate the required Expert Review via a separate request. This review must be completed before the document's IANA state can be changed to "IANA OK."

Second, in the Status Codes registry also on the Dynamic Host Configuration Protocol for IPv6 (DHCPv6) registry page located at:

https://www.iana.org/assignments/dhcpv6-parameters/

a single, new registration is to be made as follows:

Value: [ TBD-at-Registration ]
Description: NoQuadAvail
Reference: [ RFC-to-be ]

The IANA Functions Operator understands that these are the only actions required to be completed upon approval of this document.

Note:  The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is meant only to confirm the list of actions that will be performed.

Thank you,

Sabrina Tanamal
Senior IANA Services Specialist
2020-05-26
08 Carl Wallace Request for Last Call review by SECDIR Completed: Ready. Reviewer: Carl Wallace.
2020-05-19
08 Gunter Van de Velde Request for Last Call review by OPSDIR is assigned to Susan Hares
2020-05-19
08 Gunter Van de Velde Request for Last Call review by OPSDIR is assigned to Susan Hares
2020-05-18
08 Tatuya Jinmei Request for Last Call review by INTDIR Completed: Ready with Issues. Reviewer: Tatuya Jinmei. Sent review to list.
2020-05-14
08 Samita Chakrabarti Request for Last Call review by IOTDIR is assigned to Jaime Jimenez
2020-05-14
08 Samita Chakrabarti Request for Last Call review by IOTDIR is assigned to Jaime Jimenez
2020-05-14
08 Jean Mahoney Request for Last Call review by GENART is assigned to Ines Robles
2020-05-14
08 Jean Mahoney Request for Last Call review by GENART is assigned to Ines Robles
2020-05-14
08 Tero Kivinen Request for Last Call review by SECDIR is assigned to Carl Wallace
2020-05-14
08 Tero Kivinen Request for Last Call review by SECDIR is assigned to Carl Wallace
2020-05-13
08 Amy Vezza
The following Last Call announcement was sent out (ends 2020-05-27):

From: The IESG
To: IETF-Announce
CC: draft-ietf-dhc-slap-quadrant@ietf.org, ianfarrer@gmx.com, Tomek Mrugalski , Ian Farrer …
The following Last Call announcement was sent out (ends 2020-05-27):

From: The IESG
To: IETF-Announce
CC: draft-ietf-dhc-slap-quadrant@ietf.org, ianfarrer@gmx.com, Tomek Mrugalski , Ian Farrer , evyncke@cisco.com, dhc-chairs@ietf.org, dhcwg@ietf.org
Reply-To: last-call@ietf.org
Sender:
Subject: Last Call:  (SLAP quadrant selection options for DHCPv6) to Proposed Standard


The IESG has received a request from the Dynamic Host Configuration WG (dhc)
to consider the following document: - 'SLAP quadrant selection options for
DHCPv6'
  as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
last-call@ietf.org mailing lists by 2020-05-27. Exceptionally, comments may
be sent to iesg@ietf.org instead. In either case, please retain the beginning
of the Subject line to allow automated sorting.

Abstract


  The IEEE originally structured the 48-bit MAC address space in such a
  way that half of it was reserved for local use.  Recently, the IEEE
  has been working on a new specification (IEEE 802c) which defines a
  new optional "Structured Local Address Plan" (SLAP) that specifies
  different assignment approaches in four specified regions of the
  local MAC address space.

  The IEEE is working on mechanisms to allocate addresses in the one of
  these quadrants (IEEE 802.1CQ).  There is work also in the IETF on
  specifying a new mechanism that extends DHCPv6 operation to handle
  the local MAC address assignments.  We complement this work by
  defining a mechanism to allow choosing the SLAP quadrant to use in
  the allocation of the MAC address to the requesting device/client.

  This document proposes extensions to DHCPv6 protocols to enable a
  DHCPv6 client or a DHCPv6 relay to indicate a preferred SLAP quadrant
  to the server, so that the server allocates the MAC addresses to the
  given client out of the quadrant requested by relay or client.  A new
  DHCPv6 option (OPTION_SLAP_QUAD, or QUAD) is defined for this
  purpose.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-dhc-slap-quadrant/


The following IPR Declarations may be related to this I-D:

  https://datatracker.ietf.org/ipr/4110/





2020-05-13
08 Amy Vezza IANA Review state changed to IANA - Review Needed
2020-05-13
08 Amy Vezza
The following Last Call announcement was sent out (ends 2020-05-27):

From: The IESG
To: IETF-Announce
CC: draft-ietf-dhc-slap-quadrant@ietf.org, ianfarrer@gmx.com, Tomek Mrugalski , Ian Farrer …
The following Last Call announcement was sent out (ends 2020-05-27):

From: The IESG
To: IETF-Announce
CC: draft-ietf-dhc-slap-quadrant@ietf.org, ianfarrer@gmx.com, Tomek Mrugalski , Ian Farrer , evyncke@cisco.com, dhc-chairs@ietf.org, dhcwg@ietf.org
Reply-To: last-call@ietf.org
Sender:
Subject: Last Call:  (SLAP quadrant selection options for DHCPv6) to Proposed Standard


The IESG has received a request from the Dynamic Host Configuration WG (dhc)
to consider the following document: - 'SLAP quadrant selection options for
DHCPv6'
  as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
last-call@ietf.org mailing lists by 2020-05-27. Exceptionally, comments may
be sent to iesg@ietf.org instead. In either case, please retain the beginning
of the Subject line to allow automated sorting.

Abstract


  The IEEE originally structured the 48-bit MAC address space in such a
  way that half of it was reserved for local use.  Recently, the IEEE
  has been working on a new specification (IEEE 802c) which defines a
  new optional "Structured Local Address Plan" (SLAP) that specifies
  different assignment approaches in four specified regions of the
  local MAC address space.

  The IEEE is working on mechanisms to allocate addresses in the one of
  these quadrants (IEEE 802.1CQ).  There is work also in the IETF on
  specifying a new mechanism that extends DHCPv6 operation to handle
  the local MAC address assignments.  We complement this work by
  defining a mechanism to allow choosing the SLAP quadrant to use in
  the allocation of the MAC address to the requesting device/client.

  This document proposes extensions to DHCPv6 protocols to enable a
  DHCPv6 client or a DHCPv6 relay to indicate a preferred SLAP quadrant
  to the server, so that the server allocates the MAC addresses to the
  given client out of the quadrant requested by relay or client.  A new
  DHCPv6 option (OPTION_SLAP_QUAD, or QUAD) is defined for this
  purpose.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-dhc-slap-quadrant/


The following IPR Declarations may be related to this I-D:

  https://datatracker.ietf.org/ipr/4110/





2020-05-13
08 Amy Vezza IESG state changed to In Last Call from Last Call Requested
2020-05-13
08 Carlos Jesús Bernardos Request for Last Call review by INTDIR is assigned to Tatuya Jinmei
2020-05-13
08 Carlos Jesús Bernardos Request for Last Call review by INTDIR is assigned to Tatuya Jinmei
2020-05-13
08 Éric Vyncke Requested Last Call review by INTDIR
2020-05-13
08 Éric Vyncke Requested Last Call review by IOTDIR
2020-05-13
08 Éric Vyncke Last call was requested
2020-05-13
08 Éric Vyncke Last call announcement was generated
2020-05-13
08 Éric Vyncke Ballot approval text was generated
2020-05-13
08 Éric Vyncke Ballot writeup was generated
2020-05-13
08 Éric Vyncke After the authors have modified the I-D based on off-list AD review.
2020-05-13
08 Éric Vyncke IESG state changed to Last Call Requested from AD Evaluation::AD Followup
2020-05-13
08 (System) Sub state has been changed to AD Followup from Revised ID Needed
2020-05-13
08 Carlos Jesús Bernardos New version available: draft-ietf-dhc-slap-quadrant-08.txt
2020-05-13
08 (System) New version approved
2020-05-13
08 (System) Request for posting confirmation emailed to previous authors: Alain Mourad , Carlos Bernardos
2020-05-13
08 Carlos Jesús Bernardos Uploaded new revision
2020-05-12
07 Ian Farrer
This version is dated 1 November 2019.

(1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why …
This version is dated 1 November 2019.

(1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why is this the proper type of RFC? Is this type of RFC indicated in the title page header?

Intended Status: Standards Track (Indicated on title page)
This document extends draft-ietf-dhc-mac-assign (Link-Layer Addresses Assignment Mechanism for DHCPv6 - also intended for Standards Track and intended to progress alongside this document), to enable clients and relays to indicate preferences for which 'Structured Local Address Plan' (SLAP) region [IEEEStd802c-2017] the server should allocate addresses from.

(2) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up. Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections:

Technical Summary

IEEE 802c includes new assignment approaches for MAC addresses. This defines four regions (quadrants) of the local MAC address space, each with their own set of semantics.
draft-ietf-dhc-mac-assign defines a new mechanism enabling clients to request leasing of link-layer addressing by extending existing DHCPv6 processes. This draft extends
draft-ietf-dhc-mac-assign giving DHCP clients and relays a mechanism to indicate preferences for the SLAP quadrant that the server should allocate L2 addresses from.
One new DHCPv6 option is defined for this purpose.

Working Group Summary

This document has been progressed through the DHC workgroup. There is consensus in the WG for the publication of this document. No points or controversy has been raised during the authoring or review process.

Document Quality

Are there existing implementations of the protocol? Have a significant number of vendors indicated their plan to implement the specification? Are there any reviewers that merit special mention as having done a thorough review, e.g., one that resulted in important changes or a conclusion that the document had no substantive issues? If there was a MIB Doctor, YANG Doctor, Media Type or other expert review, what was its course (briefly)? In the case of a Media Type review, on what date was the request posted?

There are no existing implementations of the specification. One of the authors (C. Bernandos) stated that he is involved in an EU project which may implement.

Personnel:

Who is the Document Shepherd? Who is the Responsible Area Director?

Ian Farrer is the Document Shepherd.
Éric Vyncke is the Area Director

(3) Briefly describe the review of this document that was performed by the Document Shepherd. If this version of the document is not ready for publication, please explain why the document is being forwarded to the IESG.

The document has been reviewed by the Document Shepherd for technical content, completeness and language. All raised comments have been resolved.
The document is well written and ready for publication.

(4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed?

No.

(5) Do portions of the document need review from a particular or from broader perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or internationalization? If so, describe the review that took place.

No.

(6) Describe any specific concerns or issues that the Document Shepherd has with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the interested community has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here.

None.

(7) Has each author confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed. If not, explain why.

Yes.

(8) Has an IPR disclosure been filed that references this document? If so, summarize any discussion and conclusion regarding the IPR disclosures.

No.

(9) How solid is the consensus of the interested community behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the interested community as a whole understand and agree with it?

WG consensus has been achieved and all of the active participants agree on the advancement of this document.

(10) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is publicly available.)

No.

(11) Identify any ID nits the Document Shepherd has found in this document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough.

ID nits reports an outdated informal reference to draft-ietf-dhc-mac-assign-04 but as the referenced document is being submitted at the same time, and it is expected that the two documents will be in the same cluster, this will be resolved in the publication process.

(12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.

No formal reviews are necessary.

(13) Have all references within this document been identified as either normative or informative?

Yes.

(14) Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the plan for their completion?

No.

(15) Are there downward normative references references (see RFC 3967)? If so, list these downward references to support the Area Director in the Last Call procedure.

No.

(16) Will publication of this document change the status of any existing RFCs? Are those RFCs listed on the title page header, listed in the abstract, and discussed in the introduction? If the RFCs are not listed in the Abstract and Introduction, explain why, and point to the part of the document where the relationship of this document to the other RFCs is discussed. If this information is not in the document, explain why the interested community considers it unnecessary.

No.

(17) Describe the Document Shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the document. Confirm that all protocol extensions that the document makes are associated with the appropriate reservations in IANA registries. Confirm that any referenced IANA registries have been clearly identified. Confirm that newly created IANA registries include a detailed specification of the initial contents for the registry, that allocations procedures for future registrations are defined, and a reasonable name for the new registry has been suggested (see RFC 8126).

The IANA considerations section requests the assignment of a new DHCPv6 option code for the new DHCPv6 option defined in the document's body text. The data that is provided contains the necessary parameters for the option code assignment, including the "Client ORO" and "singleton option" values as descibed in section 24. of RFC8415.

(18) List any new IANA registries that require Expert Review for future allocations. Provide any public guidance that the IESG would find useful in selecting the IANA Experts for these new registries.

No registries requiring Expert Review are defined.

(19) Describe reviews and automated checks performed by to validate sections of the document written in a formal language, such as XML code, BNF rules, MIB definitions, YANG modules, etc.

None (no formal language is included in the document).

(20) If the document contains a YANG module, has the module been checked with any of the recommended validation tools (https://trac.ietf.org/trac/ops/wiki/yang-review-tools) for syntax and formatting validation? If there are any resulting errors or warnings, what is the justification for not fixing them at this time? Does the YANG module comply with the Network Management Datastore Architecture (NMDA) as specified in RFC8342?

No YANG is included in the document.
2020-05-11
07 Éric Vyncke Sent AD review off-list to authors (mainly nits)
2020-05-11
07 Éric Vyncke IESG state changed to AD Evaluation::Revised I-D Needed from AD Evaluation
2020-04-24
Jenny Bui Posted related IPR disclosure InterDigital Patent Holdings, Inc.'s Statement about IPR related to draft-ietf-dhc-slap-quadrant
2020-04-20
07 Éric Vyncke IESG state changed to AD Evaluation from Publication Requested
2020-04-16
07 Bernie Volz
This version is dated 1 November 2019.

(1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why …
This version is dated 1 November 2019.

(1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why is this the proper type of RFC? Is this type of RFC indicated in the title page header?

Intended Status: Standards Track (Indicated on title page)
This document extends draft-ietf-dhc-mac-assign (Link-Layer Addresses Assignment Mechanism for DHCPv6 - also intended for Standards Track and intended to progress alongside this document), to enable clients and relays to indicate preferences for which 'Structured Local Address Plan' (SLAP) region [IEEEStd802c-2017] the server should allocate addresses from.

(2) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up. Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections:

Technical Summary

IEEE 802c includes new assignment approaches for MAC addresses. This defines four regions (quadrants) of the local MAC address space, each with their own set of semantics.
draft-ietf-dhc-mac-assign defines a new mechanism enabling clients to request leasing of link-layer addressing by extending existing DHCPv6 processes. This draft extends
draft-ietf-dhc-mac-assign giving DHCP clients and relays a mechanism to indicate preferences for the SLAP quadrant that the server should allocate L2 addresses from.
One new DHCPv6 option is defined for this purpose.

Working Group Summary

This document has been progressed through the DHC workgroup. There is consensus in the WG for the publication of this document. No points or controversy has been raised during the authoring or review
process.

Document Quality

Are there existing implementations of the protocol? Have a significant number of vendors indicated their plan to implement the specification? Are there any reviewers that merit special mention as having done a thorough review, e.g., one that resulted in important changes or a conclusion that the document had no substantive issues? If there was a MIB Doctor, YANG Doctor, Media Type or other expert review, what was its course (briefly)? In the case of a Media Type review, on what date was the request posted?

There are no existing implementations of the specification. One of the authors (C. Bernandos) stated that he is involved in an EU project which may implement.

Personnel:

Who is the Document Shepherd? Who is the Responsible Area Director?

Ian Farrer is the Document Shepherd.
Erik Vyncke is the Area Director

(3) Briefly describe the review of this document that was performed by the Document Shepherd. If this version of the document is not ready for publication, please explain why the document is being forwarded to the IESG.

The document has been reviewed by the Document Shepherd for technical content, completeness and language. All raised comments have been resolved.
The document is well written and ready for publication.

(4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed?

No.

(5) Do portions of the document need review from a particular or from broader perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or internationalization? If so, describe the review that took place.

No.

(6) Describe any specific concerns or issues that the Document Shepherd has with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the interested community has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here.

None.

(7) Has each author confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed. If not, explain why.

Yes.

(8) Has an IPR disclosure been filed that references this document? If so, summarize any discussion and conclusion regarding the IPR disclosures.

No.

(9) How solid is the consensus of the interested community behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the interested community as a whole understand and agree with it?

WG consensus has been achieved and all of the active participants agree on the advancement of this document. As both of the DHCWG chairs are co-authors of this document,

(10) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is publicly available.)

No.

(11) Identify any ID nits the Document Shepherd has found in this document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough.

ID nits reports an outdated informal reference to draft-ietf-dhc-mac-assign-04 but as the referenced document is being submitted at the same time, and it is expected that the two documents will be in the same cluster, this will be resolved in the publication process.

(12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.

No formal reviews are necessary.

(13) Have all references within this document been identified as either normative or informative?

Yes.

(14) Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the plan for their completion?

No.

(15) Are there downward normative references references (see RFC 3967)? If so, list these downward references to support the Area Director in the Last Call procedure.

No.

(16) Will publication of this document change the status of any existing RFCs? Are those RFCs listed on the title page header, listed in the abstract, and discussed in the introduction? If the RFCs are not listed in the Abstract and Introduction, explain why, and point to the part of the document where the relationship of this document to the other RFCs is discussed. If this information is not in the document, explain why the interested community considers it unnecessary.

No.

(17) Describe the Document Shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the document. Confirm that all protocol extensions that the document makes are associated with the appropriate reservations in IANA registries. Confirm that any referenced IANA registries have been clearly identified. Confirm that newly created IANA registries include a detailed specification of the initial contents for the registry, that allocations procedures for future registrations are defined, and a reasonable name for the new registry has been suggested (see RFC 8126).

The IANA considerations section requests the assignment of a new DHCPv6 option code for the new DHCPv6 option defined in the document's body text. The data that is provided contains the necessary parameters for the option code assignment, including the "Client ORO" and "singleton option" values as descibed in section 24. of RFC8415.

(18) List any new IANA registries that require Expert Review for future allocations. Provide any public guidance that the IESG would find useful in selecting the IANA Experts for these new registries.

No registries requiring Expert Review are defined.

(19) Describe reviews and automated checks performed by to validate sections of the document written in a formal language, such as XML code, BNF rules, MIB definitions, YANG modules, etc.

None (no formal language is included in the document).

(20) If the document contains a YANG module, has the module been checked with any of the recommended validation tools (https://trac.ietf.org/trac/ops/wiki/yang-review-tools) for syntax and formatting validation? If there are any resulting errors or warnings, what is the justification for not fixing them at this time? Does the YANG module comply with the Network Management Datastore Architecture (NMDA) as specified in RFC8342?

No YANG is included in the document.
2020-04-16
07 Bernie Volz Responsible AD changed to Éric Vyncke
2020-04-16
07 Bernie Volz IETF WG state changed to Submitted to IESG for Publication from Waiting for WG Chair Go-Ahead
2020-04-16
07 Bernie Volz IESG state changed to Publication Requested from I-D Exists
2020-04-16
07 Bernie Volz IESG process started in state Publication Requested
2020-04-16
07 Bernie Volz Tags Doc Shepherd Follow-up Underway, Revised I-D Needed - Issue raised by WGLC cleared.
2020-04-16
07 Ian Farrer
This version is dated 1 November 2019.

(1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why …
This version is dated 1 November 2019.

(1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why is this the proper type of RFC? Is this type of RFC indicated in the title page header?

Intended Status: Standards Track (Indicated on title page)
This document extends draft-ietf-dhc-mac-assign (Link-Layer Addresses Assignment Mechanism for DHCPv6 - also intended for Standards Track and intended to progress alongside this document), to enable clients and relays to indicate preferences for which 'Structured Local Address Plan' (SLAP) region [IEEEStd802c-2017] the server should allocate addresses from.

(2) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up. Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections:

Technical Summary

IEEE 802c includes new assignment approaches for MAC addresses. This defines four regions (quadrants) of the local MAC address space, each with their own set of semantics.
draft-ietf-dhc-mac-assign defines a new mechanism enabling clients to request leasing of link-layer addressing by extending existing DHCPv6 processes. This draft extends
draft-ietf-dhc-mac-assign giving DHCP clients and relays a mechanism to indicate preferences for the SLAP quadrant that the server should allocate L2 addresses from.
One new DHCPv6 option is defined for this purpose.

Working Group Summary

This document has been progressed through the DHC workgroup. There is consensus in the WG for the publication of this document. No points or controversy has been raised during the authoring or review
process.

Document Quality

Are there existing implementations of the protocol? Have a significant number of vendors indicated their plan to implement the specification? Are there any reviewers that merit special mention as having done a thorough review, e.g., one that resulted in important changes or a conclusion that the document had no substantive issues? If there was a MIB Doctor, YANG Doctor, Media Type or other expert review, what was its course (briefly)? In the case of a Media Type review, on what date was the request posted?

There are no existing implementations of the specification. One of the authors (C. Bernandos) stated that he is involved in an EU project which may implement.

Personnel:

Who is the Document Shepherd? Who is the Responsible Area Director?

Ian Farrer is the Document Shepherd.
Erik Vyncke is the Area Director

(3) Briefly describe the review of this document that was performed by the Document Shepherd. If this version of the document is not ready for publication, please explain why the document is being forwarded to the IESG.

The document has been reviewed by the Document Shepherd for technical content, completeness and language. All raised comments have been resolved.
The document is well written and ready for publication.

(4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed?

No.

(5) Do portions of the document need review from a particular or from broader perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or internationalization? If so, describe the review that took place.

No.

(6) Describe any specific concerns or issues that the Document Shepherd has with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the interested community has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here.

None.

(7) Has each author confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed. If not, explain why.

Yes.

(8) Has an IPR disclosure been filed that references this document? If so, summarize any discussion and conclusion regarding the IPR disclosures.

No.

(9) How solid is the consensus of the interested community behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the interested community as a whole understand and agree with it?

WG consensus has been achieved and all of the active participants agree on the advancement of this document. As both of the DHCWG chairs are co-authors of this document,

(10) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is publicly available.)

No.

(11) Identify any ID nits the Document Shepherd has found in this document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough.

ID nits reports an outdated informal reference to draft-ietf-dhc-mac-assign-04 but as the referenced document is being submitted at the same time, and it is expected that the two documents will be in the same cluster, this will be resolved in the publication process.

(12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.

No formal reviews are necessary.

(13) Have all references within this document been identified as either normative or informative?

Yes.

(14) Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the plan for their completion?

No.

(15) Are there downward normative references references (see RFC 3967)? If so, list these downward references to support the Area Director in the Last Call procedure.

No.

(16) Will publication of this document change the status of any existing RFCs? Are those RFCs listed on the title page header, listed in the abstract, and discussed in the introduction? If the RFCs are not listed in the Abstract and Introduction, explain why, and point to the part of the document where the relationship of this document to the other RFCs is discussed. If this information is not in the document, explain why the interested community considers it unnecessary.

No.

(17) Describe the Document Shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the document. Confirm that all protocol extensions that the document makes are associated with the appropriate reservations in IANA registries. Confirm that any referenced IANA registries have been clearly identified. Confirm that newly created IANA registries include a detailed specification of the initial contents for the registry, that allocations procedures for future registrations are defined, and a reasonable name for the new registry has been suggested (see RFC 8126).

The IANA considerations section requests the assignment of a new DHCPv6 option code for the new DHCPv6 option defined in the document's body text. The data that is provided contains the necessary parameters for the option code assignment, including the "Client ORO" and "singleton option" values as descibed in section 24. of RFC8415.

(18) List any new IANA registries that require Expert Review for future allocations. Provide any public guidance that the IESG would find useful in selecting the IANA Experts for these new registries.

No registries requiring Expert Review are defined.

(19) Describe reviews and automated checks performed by to validate sections of the document written in a formal language, such as XML code, BNF rules, MIB definitions, YANG modules, etc.

None (no formal language is included in the document).

(20) If the document contains a YANG module, has the module been checked with any of the recommended validation tools (https://trac.ietf.org/trac/ops/wiki/yang-review-tools) for syntax and formatting validation? If there are any resulting errors or warnings, what is the justification for not fixing them at this time? Does the YANG module comply with the Network Management Datastore Architecture (NMDA) as specified in RFC8342?

No YANG is included in the document.
2020-04-14
07 Carlos Jesús Bernardos New version available: draft-ietf-dhc-slap-quadrant-07.txt
2020-04-14
07 (System) New version approved
2020-04-14
07 (System) Request for posting confirmation emailed to previous authors: Alain Mourad , Carlos Bernardos
2020-04-14
07 Carlos Jesús Bernardos Uploaded new revision
2020-04-06
06 Ian Farrer
This version is dated 1 November 2019.

(1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why …
This version is dated 1 November 2019.

(1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why is this the proper type of RFC? Is this type of RFC indicated in the title page header?

Intended Status: Standards Track (Indicated on title page)
This document extends draft-ietf-dhc-mac-assign (Link-Layer Addresses Assignment Mechanism for DHCPv6 - also intended for Standards Track and intended to progress alongside this document), to enable clients and relays to indicate preferences for which 'Structured Local Address Plan' (SLAP) region [IEEEStd802c-2017] the server should allocate addresses from.

(2) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up. Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections:

Technical Summary

IEEE 802c includes new assignment approaches for MAC addresses. This defines four regions (quadrants) of the local MAC address space, each with their own set of semantics.
draft-ietf-dhc-mac-assign defines a new mechanism enabling clients to request leasing of link-layer addressing by extending existing DHCPv6 processes. This draft extends
draft-ietf-dhc-mac-assign giving DHCP clients and relays a mechanism to indicate preferences for the SLAP quadrant that the server should allocate L2 addresses from.
One new DHCPv6 option is defined for this purpose.

Working Group Summary

This document has been progressed through the DHC workgroup. There is consensus in the WG for the publication of this document. No points or controversy has been raised during the authoring or review
process.

Document Quality

Are there existing implementations of the protocol? Have a significant number of vendors indicated their plan to implement the specification? Are there any reviewers that merit special mention as having done a thorough review, e.g., one that resulted in important changes or a conclusion that the document had no substantive issues? If there was a MIB Doctor, YANG Doctor, Media Type or other expert review, what was its course (briefly)? In the case of a Media Type review, on what date was the request posted?

There are no existing implementations of the specification. One of the authors (C. Bernandos) stated that he is involved in an EU project which may implement.

Personnel:

Who is the Document Shepherd? Who is the Responsible Area Director?

Ian Farrer is the Document Shepherd.
Suresh Krishnan is the Area Director

(3) Briefly describe the review of this document that was performed by the Document Shepherd. If this version of the document is not ready for publication, please explain why the document is being forwarded to the IESG.

The document has been reviewed by the Document Shepherd for technical content, completeness and language. All raised comments have been resolved.
The document is well written and ready for publication.

(4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed?

No.

(5) Do portions of the document need review from a particular or from broader perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or internationalization? If so, describe the review that took place.

No.

(6) Describe any specific concerns or issues that the Document Shepherd has with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the interested community has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here.

None.

(7) Has each author confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed. If not, explain why.

Yes.

(8) Has an IPR disclosure been filed that references this document? If so, summarize any discussion and conclusion regarding the IPR disclosures.

No.

(9) How solid is the consensus of the interested community behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the interested community as a whole understand and agree with it?

WG consensus has been achieved and all of the active participants agree on the advancement of this document. As both of the DHCWG chairs are co-authors of this document,

(10) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is publicly available.)

No.

(11) Identify any ID nits the Document Shepherd has found in this document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough.

ID nits reports an outdated informal reference to draft-ietf-dhc-mac-assign-04 but as the referenced document is being submitted at the same time, and it is expected that the two documents will be in the same cluster, this will be resolved in the publication process.

(12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.

No formal reviews are necessary.

(13) Have all references within this document been identified as either normative or informative?

Yes.

(14) Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the plan for their completion?

No.

(15) Are there downward normative references references (see RFC 3967)? If so, list these downward references to support the Area Director in the Last Call procedure.

No.

(16) Will publication of this document change the status of any existing RFCs? Are those RFCs listed on the title page header, listed in the abstract, and discussed in the introduction? If the RFCs are not listed in the Abstract and Introduction, explain why, and point to the part of the document where the relationship of this document to the other RFCs is discussed. If this information is not in the document, explain why the interested community considers it unnecessary.

No.

(17) Describe the Document Shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the document. Confirm that all protocol extensions that the document makes are associated with the appropriate reservations in IANA registries. Confirm that any referenced IANA registries have been clearly identified. Confirm that newly created IANA registries include a detailed specification of the initial contents for the registry, that allocations procedures for future registrations are defined, and a reasonable name for the new registry has been suggested (see RFC 8126).

The IANA considerations section requests the assignment of a new DHCPv6 option code for the new DHCPv6 option defined in the document's body text. The data that is provided contains the necessary parameters for the option code assignment, including the "Client ORO" and "singleton option" values as descibed in section 24. of RFC8415.

(18) List any new IANA registries that require Expert Review for future allocations. Provide any public guidance that the IESG would find useful in selecting the IANA Experts for these new registries.

No registries requiring Expert Review are defined.

(19) Describe reviews and automated checks performed by to validate sections of the document written in a formal language, such as XML code, BNF rules, MIB definitions, YANG modules, etc.

None (no formal language is included in the document).

(20) If the document contains a YANG module, has the module been checked with any of the recommended validation tools (https://trac.ietf.org/trac/ops/wiki/yang-review-tools) for syntax and formatting validation? If there are any resulting errors or warnings, what is the justification for not fixing them at this time? Does the YANG module comply with the Network Management Datastore Architecture (NMDA) as specified in RFC8342?

No YANG is included in the document.
2020-04-06
06 Ian Farrer
This version is dated 1 November 2019.

(1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why …
This version is dated 1 November 2019.

(1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why is this the proper type of RFC? Is this type of RFC indicated in the title page header?

Intended Status: Standards Track (Indicated on title page)
This document extends draft-ietf-dhc-mac-assign (Link-Layer Addresses Assignment Mechanism for DHCPv6 - also intended for Standards Track and intended to progress alongside this document), to enable clients and relays to indicate preferences for which 'Structured Local Address Plan' (SLAP) region [IEEEStd802c-2017] the server should allocate addresses from.

(2) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up. Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections:

Technical Summary

IEEE 802c includes new assignment approaches for MAC addresses. This defines four regions (quadrants) of the local MAC address space, each with their own set of semantics.
draft-ietf-dhc-mac-assign defines a new mechanism enabling clients to request leasing of link-layer addressing by extending existing DHCPv6 processes. This draft extends
draft-ietf-dhc-mac-assign giving DHCP clients and relays a mechanism to indicate preferences for the SLAP quadrant that the server should allocate L2 addresses from.
One new DHCPv6 option is defined for this purpose.

Working Group Summary

This document has been progressed through the DHC workgroup. There is consensus in the WG for the publication of this document. No points or controversy has been raised during the authoring or review
process.

Document Quality

Are there existing implementations of the protocol? Have a significant number of vendors indicated their plan to implement the specification? Are there any reviewers that merit special mention as having done a thorough review, e.g., one that resulted in important changes or a conclusion that the document had no substantive issues? If there was a MIB Doctor, YANG Doctor, Media Type or other expert review, what was its course (briefly)? In the case of a Media Type review, on what date was the request posted?

There are no existing implementations of the specification. One of the authors (C. Bernandos) stated that he is involved in an EU project which may implement.

Personnel:

Who is the Document Shepherd? Who is the Responsible Area Director?

Ian Farrer is the Document Shepherd.
Suresh Krishnan is the Area Director

(3) Briefly describe the review of this document that was performed by the Document Shepherd. If this version of the document is not ready for publication, please explain why the document is being forwarded to the IESG.

The document has been reviewed by the Document Shepherd for technical content, completeness and language. All raised comments have been resolved.
The document is well written and ready for publication.

(4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed?

No.

(5) Do portions of the document need review from a particular or from broader perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or internationalization? If so, describe the review that took place.

No.

(6) Describe any specific concerns or issues that the Document Shepherd has with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the interested community has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here.

None.

(7) Has each author confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed. If not, explain why.

Waiting on Alain Mourand.

(8) Has an IPR disclosure been filed that references this document? If so, summarize any discussion and conclusion regarding the IPR disclosures.

No.

(9) How solid is the consensus of the interested community behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the interested community as a whole understand and agree with it?

WG consensus has been achieved and all of the active participants agree on the advancement of this document. As both of the DHCWG chairs are co-authors of this document,

(10) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is publicly available.)

No.

(11) Identify any ID nits the Document Shepherd has found in this document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough.

ID nits reports an outdated informal reference to draft-ietf-dhc-mac-assign-04 but as the referenced document is being submitted at the same time, and it is expected that the two documents will be in the same cluster, this will be resolved in the publication process.

(12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.

No formal reviews are necessary.

(13) Have all references within this document been identified as either normative or informative?

Yes.

(14) Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the plan for their completion?

No.

(15) Are there downward normative references references (see RFC 3967)? If so, list these downward references to support the Area Director in the Last Call procedure.

No.

(16) Will publication of this document change the status of any existing RFCs? Are those RFCs listed on the title page header, listed in the abstract, and discussed in the introduction? If the RFCs are not listed in the Abstract and Introduction, explain why, and point to the part of the document where the relationship of this document to the other RFCs is discussed. If this information is not in the document, explain why the interested community considers it unnecessary.

No.

(17) Describe the Document Shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the document. Confirm that all protocol extensions that the document makes are associated with the appropriate reservations in IANA registries. Confirm that any referenced IANA registries have been clearly identified. Confirm that newly created IANA registries include a detailed specification of the initial contents for the registry, that allocations procedures for future registrations are defined, and a reasonable name for the new registry has been suggested (see RFC 8126).

The IANA considerations section requests the assignment of a new DHCPv6 option code for the new DHCPv6 option defined in the document's body text. The data that is provided contains the necessary parameters for the option code assignment, including the "Client ORO" and "singleton option" values as descibed in section 24. of RFC8415.

(18) List any new IANA registries that require Expert Review for future allocations. Provide any public guidance that the IESG would find useful in selecting the IANA Experts for these new registries.

No registries requiring Expert Review are defined.

(19) Describe reviews and automated checks performed by to validate sections of the document written in a formal language, such as XML code, BNF rules, MIB definitions, YANG modules, etc.

None (no formal language is included in the document).

(20) If the document contains a YANG module, has the module been checked with any of the recommended validation tools (https://trac.ietf.org/trac/ops/wiki/yang-review-tools) for syntax and formatting validation? If there are any resulting errors or warnings, what is the justification for not fixing them at this time? Does the YANG module comply with the Network Management Datastore Architecture (NMDA) as specified in RFC8342?

No YANG is included in the document.
2020-03-16
06 Carlos Jesús Bernardos New version available: draft-ietf-dhc-slap-quadrant-06.txt
2020-03-16
06 (System) New version accepted (logged-in submitter: Carlos Bernardos)
2020-03-16
06 Carlos Jesús Bernardos Uploaded new revision
2020-03-07
05 Carlos Jesús Bernardos New version available: draft-ietf-dhc-slap-quadrant-05.txt
2020-03-07
05 (System) New version approved
2020-03-07
05 (System) Request for posting confirmation emailed to previous authors: Alain Mourad , Carlos Bernardos
2020-03-07
05 Carlos Jesús Bernardos Uploaded new revision
2020-02-28
04 Carlos Jesús Bernardos New version available: draft-ietf-dhc-slap-quadrant-04.txt
2020-02-28
04 (System) New version approved
2020-02-28
04 (System) Request for posting confirmation emailed to previous authors: Carlos Bernardos , Alain Mourad
2020-02-28
04 Carlos Jesús Bernardos Uploaded new revision
2020-02-27
03 Carlos Jesús Bernardos New version available: draft-ietf-dhc-slap-quadrant-03.txt
2020-02-27
03 (System) New version approved
2020-02-27
03 (System) Request for posting confirmation emailed to previous authors: Alain Mourad , Carlos Bernardos
2020-02-27
03 Carlos Jesús Bernardos Uploaded new revision
2020-01-15
02 Bernie Volz Waiting for shepherd and authors to work out some remaining issues to improve document.
2020-01-15
02 Bernie Volz Tags Revised I-D Needed - Issue raised by WGLC, Doc Shepherd Follow-up Underway set.
2020-01-15
02 Bernie Volz IETF WG state changed to Waiting for WG Chair Go-Ahead from In WG Last Call
2020-01-13
02 Carlos Jesús Bernardos New version available: draft-ietf-dhc-slap-quadrant-02.txt
2020-01-13
02 (System) New version approved
2020-01-13
02 (System) Request for posting confirmation emailed to previous authors: Alain Mourad , Carlos Bernardos
2020-01-13
02 Carlos Jesús Bernardos Uploaded new revision
2020-01-09
01 (System) Document has expired
2019-12-23
01 Bernie Volz Notification list changed to Tomek Mrugalski <tomasz.mrugalski@gmail.com>, Ian Farrer <ianfarrer@gmx.com> from Tomek Mrugalski <tomasz.mrugalski@gmail.com>
2019-12-23
01 Bernie Volz Document shepherd changed to Ian Farrer
2019-10-29
01 Tomek Mrugalski IETF WG state changed to In WG Last Call from WG Document
2019-09-25
01 Bernie Volz Notification list changed to Tomek Mrugalski <tomasz.mrugalski@gmail.com>
2019-09-25
01 Bernie Volz Document shepherd changed to Tomek Mrugalski
2019-07-08
01 Carlos Jesús Bernardos New version available: draft-ietf-dhc-slap-quadrant-01.txt
2019-07-08
01 (System) New version approved
2019-07-08
01 (System) Request for posting confirmation emailed to previous authors: Alain Mourad , Carlos Bernardos
2019-07-08
01 Carlos Jesús Bernardos Uploaded new revision
2019-04-24
00 Bernie Volz Changed consensus to Yes from Unknown
2019-04-24
00 Bernie Volz Intended Status changed to Proposed Standard from None
2019-04-24
00 Bernie Volz This document now replaces draft-bernardos-dhc-slap-quadrant instead of None
2019-04-24
00 Carlos Jesús Bernardos New version available: draft-ietf-dhc-slap-quadrant-00.txt
2019-04-24
00 (System) WG -00 approved
2019-04-24
00 Carlos Jesús Bernardos Set submitter to ""Carlos J. Bernardos" ", replaces to draft-bernardos-dhc-slap-quadrant and sent approval email to group chairs: dhc-chairs@ietf.org
2019-04-24
00 Carlos Jesús Bernardos Uploaded new revision