[Gen-art] Genart telechat review of draft-ietf-ospf-link-overload-12

[Joel Halpern]

Reviewer: Joel Halpern
Review result: Ready

I am the assigned Gen-ART reviewer for this draft. The General Area
Review Team (Gen-ART) reviews all IETF documents being processed
by the IESG for the IETF Chair. Please wait for direction from your
document shepherd or AD before posting a new version of the draft.

For more information, please see the FAQ at

.

Document: draft-ietf-ospf-link-overload-12
Reviewer: Joel Halpern
Review Date: 2018-01-18
IETF LC End Date: 2018-01-16
IESG Telechat date: 2018-01-25

Summary: This document is ready for publication as a Proposed Standard RFC.
My thanks to the authors and WG for addressing my concerns about naming.

Major issues: N/A

Minor issues: N/A

Nits/editorial comments:  N/A


___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

[Gen-art] Review Assignments

[Jean Mahoney]

Hi all,

The following reviewers have assignments:

For telechat 2018-01-25

Reviewer   Type  LC end Draft
Jari Arkko Telechat  2018-01-16 
draft-ietf-intarea-broadcast-consider-06
Stewart Bryant Telechat  2018-01-10 
draft-ietf-pim-source-discovery-bsr-08 *
Francis Dupont Telechat  2018-01-15 draft-ietf-netmod-rfc8022bis-09
Fernando Gont  Last Call 2018-01-16 draft-ietf-lpwan-overview-07
Joel Halpern   Telechat  2018-01-16 draft-ietf-ospf-link-overload-12 *
Paul Kyzivat   Telechat  2017-12-13 
draft-ietf-opsawg-capwap-alt-tunnel-11 *
Meral Shirazipour  Telechat  2017-11-23 draft-ietf-mboned-mtrace-v2-22 *
Meral Shirazipour  Telechat  2018-01-08 draft-ietf-trill-p2mp-bfd-08 *

For telechat 2018-02-08

Reviewer   Type  LC end Draft
Wassim Haddad  Last Call 2018-01-31 draft-ietf-rtgwg-ni-model-06
Russ Housley   Last Call 2018-01-31 draft-ietf-rtgwg-lne-model-05
Dan Romascanu  Last Call 2018-01-31 
draft-ietf-mtgvenue-iaoc-venue-selection-process-11
Meral Shirazipour  Last Call 2018-01-31 draft-ietf-bier-mvpn-09
Robert Sparks  Last Call 2018-01-31 draft-farrel-sfc-convent-05
Peter Yee  Last Call 2018-01-26 draft-ietf-idr-bgp-prefix-sid-10

Last calls:

Reviewer   Type  LC end Draft
Jari Arkko Telechat  2018-01-10 
draft-ietf-netmod-revised-datastores-10
Jari Arkko Last Call 2018-01-02 draft-ietf-mpls-flow-ident-06
Stewart Bryant Last Call 2018-01-26 draft-ietf-ice-rfc5245bis-16
Fernando Gont  Telechat  2017-12-14 
draft-ietf-spring-segment-routing-msdc-08
Pete Resnick   Telechat  2018-01-09 draft-ietf-netmod-rfc7223bis-03
Dale WorleyLast Call 2018-01-26 draft-ietf-mmusic-trickle-ice-sip-12

* Other revision previously reviewed
** This revision already reviewed

Next in the reviewer rotation:

  Christer Holmberg
  Russ Housley
  Jouni Korhonen
  Paul Kyzivat
  Matthew Miller
  Pete Resnick
  Dan Romascanu
  Meral Shirazipour
  Robert Sparks
  Dale Worley

The LC and Telechat review templates are included below:
---

-- Begin LC Template --
I am the assigned Gen-ART reviewer for this draft. The General Area
Review Team (Gen-ART) reviews all IETF documents being processed
by the IESG for the IETF Chair.  Please treat these comments just
like any other last call comments.

For more information, please see the FAQ at

.

Document:
Reviewer:
Review Date:
IETF LC End Date:
IESG Telechat date: (if known)

Summary:

Major issues:

Minor issues:

Nits/editorial comments: 

-- End LC Template --

-- Begin Telechat Template --
I am the assigned Gen-ART reviewer for this draft. The General Area
Review Team (Gen-ART) reviews all IETF documents being processed
by the IESG for the IETF Chair. Please wait for direction from your
document shepherd or AD before posting a new version of the draft.

For more information, please see the FAQ at

.

Document:
Reviewer:
Review Date:
IETF LC End Date:
IESG Telechat date: (if known)

Summary:

Major issues:

Minor issues:

Nits/editorial comments:

-- End Telechat Template --


___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

[Gen-art] Genart telechat review of draft-ietf-dhc-rfc3315bis-10

[Elwyn Davies]

Reviewer: Elwyn Davies
Review result: Almost Ready

[This is a Last Call Review, not a telechat review].

I am the assigned Gen-ART reviewer for this draft. The General Area Review Team
(Gen-ART) reviews all IETF documents being processed by the IESG for the IETF
Chair. Please treat these comments just like any other last call comments.

For more information, please see the FAQ at

.

Document: draft-ietf-dhc-rfc3315bis-10
Reviewer: Elwyn Davies
Review Date: 2018-01-18
IETF LC End Date: 2018-01-24
IESG Telechat date: 2018-01-25

Summary:  Amost ready.  To the best of my abiity I have done a thorough check
of the merging of the various earlier documents into the new -bis and the
incorporation of the various Errata.  All seems to be good from this point of
view.  I am slightly surprised that two other RFCs (7283 and 8213) were not
subsumed into this document.  Both are pure updates of 3315 with some important
improvements and are pretty short in themselves.  I also found that the new
document did not do a good job on the interactions between relay-agents and
servers.  Particularly on the processing of options between relays and servers
and details of reception of Relay-forward messages a little more detail would
halp naive readers.  Finally the draft has not made much of an effort to
support possible alternative security algorithms - IETF policy now encourages
protocols to deal with algorithm flexibility  - DHCPv6 as it stands is pretty
thoroughly wedded to HMAC-MD5 and would need some (relatively small) IANA
improvements plus some thought to cope with different algorithms.  There are
also a fair number of nits, partly due to inconsistent cross referencing in s18.

Major Issues:
None

Minor Issues:
Non-incorporation of RFC 7283:  Is there a good reason why the update of relay
agent behaviour (which is apparently of general application across DHCPv6) is
not incorporated into this document as with several other items?  The update is
short and would be readily addressed in s19 here.  As it is one is left with 
another document with some key modifications left around rather than achieving
the unification aim of this -bis.

Non-incoporation of RFC 8213:  Similarly regarding use of IPsec for
server-relay agent comms.

Definitions of T1 andT2:  I find the definitions of T1 and T2 as replicated in
many places to be a little confusing.  T1 and T2 are actually time intervals
rather than absolute times.  I suggest a global substitution as follows: OLD:
The time at which the client contacts the server NEW: The time interval after
which the client would be expected to contact the server END

s6: Might be worth pointing out the pitfalls of defining additional stateful
services as had to be sorted out with RFC 7550.

s11.2: [This is not explicitly an issue with this document, but affects its
usage]  The list of hardware types originally listed for ARP, is now well out
of date  - in particular it doesn't cover Ethernet interfaces faster than
10Mb/s.  Perhas somebody could suggest some updates to Carlos Pignatoro (the
designated expert).

s12.2:
> A client must create at least one distinct
>IA_PD.
Is it not the case that the majority of simple hosts are not concerned with
IA_PD?  I think this needs qualifying to say that if a client is interested in
obtaining a prefix, then it has to create an IA_PD.

s18.3, s18.3.11 and s19, Recording and/or reproduction of the relay address
chain in servers: I found the lack of description of server handling of
received messages embedded in relay-forward messages in s18.3 required
considerable searching to understand what needed to be done, and there is no
mention of the expectation that the relay address chain would (or at least
might) need to be recorded to facilitate later generation of Reconfigure
messages that are originated by the server.  I think it would be helpful to add
some words about this is in s18.3 as follows: ADD (probably as new para 6, et
seq):
   All messages sent from clients may arrive encapsulated in Relay-forward
   messages. For example, if client C sent a message that was relayed by relay
   agent A to relay agent B and then to the server, the server would receive
   the following Relay-forward message to process and, in general, generate an
   appropriate Relay-reply to be returned to the client:

  msg-type:   RELAY-FORWARD
  hop-count:  1
  link-address:   0
  peer-address:   A
  Relay Message option, containing:
msg-type: RELAY-FORWARD
hop-count:0
link-address: address from link to which C is attached
peer-address: C
Relay Message option: 

  Figure xx: Relay-forward Example

   Thus the server MUST record the sequence of link addresses and peer
   addresses together with their associated hop count values to allow the
   response to the received message to be relayed through the same relay agents
   as the original c