[Gen-art] Genart last call review of draft-ietf-bess-mvpn-mib-10

[David Schinazi]

Reviewer: David Schinazi
Review result: Ready with Nits

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-bess-mvpn-mib-10
Reviewer: David Schinazi
Review Date: 2018-09-06
IETF LC End Date: 2018-09-03
IESG Telechat date: 2018-09-13

Summary: This document is clearly written and looks ready to me.

Major issues: None found.

Minor issues: None found. 

Nits/editorial comments: Typo "senstive" - please run the internet draft 
spellchecker tool.


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

Re: [Gen-art] Genart telechat review of draft-ietf-taps-minset-08

[Robert Sparks]

Aaron -

To be a bit more clear, my point is to twist the IESGs arm about recent 
pushback on WGs publishing requirements documents...


RjS


On 9/6/18 3:22 PM, Aaron Falk wrote:


On 6 Sep 2018, at 16:07, Robert Sparks wrote:

(Repeating one thing from my Last Call review for the benefit of
the IESG):

This was a big effort, and it appears that it was helpful to the folks
working on the interface document, but it's not clear how it will be
useful to implementers. The IESG should consider whether this, like
requirements documents, needs to be in the RFC series. The most likely
use I can see in the future would be for historians, and a different
and shorter presentation would serve them better.

Hi Robert-

This seems like more useful information for RFC Editor than for the 
IESG. According to RFC2026 the IESG's criteria for publication for 
Informational RFCs are:


4.2.2 Informational

... The Informational
designation is intended to provide for the timely publication of a
very broad range of responsible informational documents from many
sources, subject only to editorial considerations and to verification
that there has been adequate coordination with the standards process
(see section 4.2.3).

and

6.1.2 IESG Review and Approval

The IESG shall ... determine whether or not the technical quality
and clarity
of the specification is consistent with that expected for the
maturity level to which the specification is recommended.


So, I don't think the IESG gets to decide that it doesn't belong in an 
RFC just because it doesn't it wouldn't be useful to implementors or 
historians (only two of many RFC audiences). I suggest you take your 
concerns up with the TAPS working group, who thought it was important 
to document their analysis, and/or Heather (cc'ed).


--aaron



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

Re: [Gen-art] Genart telechat review of draft-ietf-taps-minset-08

[Aaron Falk]

On 6 Sep 2018, at 16:07, Robert Sparks wrote:

(Repeating one thing from my Last Call review for the benefit of the 
IESG):


This was a big effort, and it appears that it was helpful to the folks
working on the interface document, but it's not clear how it will be
useful to implementers. The IESG should consider  whether this, like
requirements documents, needs to be in the RFC series. The most likely
use I can see in the future would be for historians, and a different
and shorter presentation would serve them better.


Hi Robert-

This seems like more useful information for RFC Editor than for the 
IESG.  According to RFC2026 the IESG's criteria for publication for 
Informational RFCs are:




4.2.2  Informational

   ... The Informational
   designation is intended to provide for the timely publication of a
   very broad range of responsible informational documents from many
   sources, subject only to editorial considerations and to 
verification
   that there has been adequate coordination with the standards 
process

   (see section 4.2.3).


and


6.1.2  IESG Review and Approval

   The IESG shall ... determine whether or not the technical quality 
and clarity

   of the specification is consistent with that expected for the
   maturity level to which the specification is recommended.




So, I don't think the IESG gets to decide that it doesn't belong in an 
RFC just because it doesn't it wouldn't be useful to implementors or 
historians (only two of many RFC audiences).  I suggest you take your 
concerns up with the TAPS working group, who thought it was important to 
document their analysis, and/or Heather (cc'ed).


--aaron___
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-09-13

Reviewer   Type  LC end Draft
Francis Dupont Telechat  2018-08-29 draft-ietf-lisp-rfc6830bis-16
David Schinazi Last Call 2018-09-03 draft-ietf-bess-mvpn-mib-10
Robert Sparks  Telechat  2018-09-04 draft-ietf-taps-minset-08 *

Last calls:

Reviewer   Type  LC end Draft
Fernando Gont  Last Call 2018-09-20 
draft-ietf-teas-assoc-corouted-bidir-frr-06
Vijay Gurbani  Last Call 2018-09-12 
draft-ietf-isis-segment-routing-msd-15
Matthew Miller Last Call 2018-08-30 draft-ietf-extra-imap-savedate-01

* Other revision previously reviewed
** This revision already reviewed

Next in the reviewer rotation:

  Joel Halpern
  Christer Holmberg
  Russ Housley
  Erik Kline
  Jouni Korhonen
  Paul Kyzivat
  Matthew Miller
  Francesca Palombini
  Pete Resnick
  Ines Robles

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 last call review of draft-ietf-dhc-dhcp4o6-saddr-opt-04

[Elwyn Davies]

Reviewer: Elwyn Davies
Review result: Ready with Nits

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-dhcp4o6-saddr-opt-04
Reviewer: Elwyn Davies
Review Date: 2018-09-06
IETF LC End Date: 2018-09-07
IESG Telechat date: Not scheduled for a telechat

Summary: Ready with nits. Thanks - well written and almost all quite clear.

Major issues:
None

Minor issues:
s7.4:
>o  The received bindprefix6-len value is not larger than the number
>   of bytes, divided by 8, received in the bind-ipv6-prefix field.
>   (e.g. the bindprefix6-len is 128 but the bind-ipv6-prefix field is
>   only 8 bytes long).
Given that s6.1 gives a deterministic algorithm for calculating the length of
the bind-ipv6-prefix field, I don't understand why the validation does not
check that the length of the field is exactly as specified by this algorithm
rather than using it as a lower limit.

s7.5 and s8 (last para): Given that the time constraints and number of retries
will interact and are implemented in different devices, I think these two
values need some sensible defaults defined so that devices from different
sources should interoperate successfully out of the box.

Nits/editorial comments:
General: s/e.g./e.g.,/g

Abstract, sentence 2: Introduce DHCP 4o6 abbreviation: s/For DHCPv4 over
DHCPv6/For DHCPv4 over DHCPv6 (DHCP 4o6)/.

Abstract: Add mention of RFC 6346 and RFC 7598 for explanation of softwire
scheme.

Abstract, para 2: Expand ORO (Option Request Option) and give ref to rfc3315bis.

s1, para 3:  s/attached to any routable IPv6 prefix/attached to a network
segment using any routable IPv6 prefix/

s4, para 1: It would be useful to remind readers of the expansion of BR in
OPTION_S46_BR:  Maybe s/the remote IPv6 address for the softwire/the remote
IPv6 address used for the softwire border router/

s4, para 1: Expand ULA (not a well-known abbreviation).

s7.2.1, para 1: 'flash' is colloquial and may not be generally understood.  I
think it can safely be removed.

s7.4, para after bullets: s/For either of these cases,/If either check fails,/

s10: To be absolutely clear, there are two instances where the following change
ought to be made: OLD: in the table at
https://www.iana.org/assignments/dhcpv6-parameters: NEW: in the Option Codes
table at https://www.iana.org/assignments/dhcpv6-parameters: ENDS

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