Re: [Gen-art] Genart last call review of draft-ietf-babel-applicability-06

[Juliusz Chroboczek]

Dear Joel,

Thank you very much for your review.

> Nits/editorial comments:
>In section 2.2, in talking about "metric M", if I have understood properly,
>I think it would be clearer if you referred to "metric value M".

Thanks, noted.  If that's okay with you, I'll wait for the RTGDIR review
before submitting a new revision.

-- Juliusz

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

Re: [Gen-art] [babel] Genart last call review of draft-ietf-babel-rfc6126bis-10

[Juliusz Chroboczek]

Dear Russ,

Thank you very much for your review.  I agree with all of your comments
save one, I'll publish a new revision taking your comments into account as
soon as possible.

>...  A node SHOULD NOT send triggered updates
>for other reasons, such as when there is a minor fluctuation in a
>route's metric, when the selected next hop changes, or to propagate a
>new sequence number (except to satisfy a request, as specified in
>Section 3.8).

> This seem backwards to me.  Perhaps:

>...  The node MUST send triggered updates to satisfy a request, as
>specified in Section 3.8; however, a node SHOULD NOT send
>triggered updates for other reasons, including a minor fluctuation
>in a metric for a route, the selected next hop changes, or to
>propagate a new sequence number.

I disagree.  The requirement to send triggered updates is already present
in 3.8.1.1, we should not repeat it.  This section is concerned with
avoiding excessive noise.

> Section 4 says:

>A Babel packet is sent as the body of a UDP datagram, with network-
>layer hop count set to 1, destined to a well-known multicast address
>or to a unicast address, over IPv4 or IPv6; in the case of IPv6,
>these addresses are link-local.
   
> It seems to me that this should be reworded as MUST statements.

Agreed.

> Section 4.1.2 says:

>A router-id is an arbitrary 8-octet value.  A router-id MUST NOT
>consist of either all zeroes or all ones.
   
> I do not think you are referring to octets with a value of one.  I
> think you mean that the router-id cannot be 0x or
> 0x.  Please reword.

Agreed.

Thanks again,

-- Juliusz


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

Re: [Gen-art] Gen-ART Last Call review of draft-ietf-v6ops-nat64-deployment-06

[Jordi Palet Martínez]

Thanks a lot Meral!

 

Regards,

Jordi

@jordipalet

 

 

El 27/6/19 18:43, "Meral Shirazipour"  escribió:

 

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-v6ops-nat64-deployment-06

 

Reviewer: Meral Shirazipour

Review Date: 2019-06-27

IETF LC End Date: 2019-06-28

IESG Telechat date: NA

 

 

Summary: This draft is ready to be published as Informational RFC .

 

 

Major issues:

 

Minor issues:

 

Nits/editorial comments:

 

 

 

Best Regards,

Meral

---

Meral Shirazipour

Ericsson Research

www.ericsson.com



**
IPv4 is over
Are you ready for the new Internet ?
http://www.theipv6company.com
The IPv6 Company

This electronic message contains information which may be privileged or 
confidential. The information is intended to be for the exclusive use of the 
individual(s) named above and further non-explicilty authorized disclosure, 
copying, distribution or use of the contents of this information, even if 
partially, including attached files, is strictly prohibited and will be 
considered a criminal offense. If you are not the intended recipient be aware 
that any disclosure, copying, distribution or use of the contents of this 
information, even if partially, including attached files, is strictly 
prohibited, will be considered a criminal offense, so you must reply to the 
original sender to inform about this communication and delete it.

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

Re: [Gen-art] Genart last call review of draft-ietf-idr-bgp-ls-segment-routing-ext-14

[Ketan Talaulikar (ketant)]

Hi Roni/Alissa,

Thanks for your review.

Thanks,
Ketan

-Original Message-
From: Alissa Cooper  
Sent: 12 June 2019 22:48
To: Roni Even 
Cc: gen-art@ietf.org; i...@ietf.org; i...@ietf.org; 
draft-ietf-idr-bgp-ls-segment-routing-ext@ietf.org
Subject: Re: [Gen-art] Genart last call review of 
draft-ietf-idr-bgp-ls-segment-routing-ext-14

Roni, thanks for your review. I entered a No Objection ballot.

Alissa

> On May 20, 2019, at 7:18 AM, Roni Even via Datatracker  
> wrote:
> 
> Reviewer: Roni Even
> 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 treat these comments just like 
> any other last call comments.
> 
> For more information, please see the FAQ at
> 
> .
> 
> Document: draft-ietf-idr-bgp-ls-segment-routing-ext-??
> Reviewer: Roni Even
> Review Date: 2019-05-20
> IETF LC End Date: 2019-05-23
> IESG Telechat date: Not scheduled for a telechat
> 
> Summary: 
> The document is ready for publication as a standard track RFC
> 
> Major issues:
> 
> Minor issues:
> 
> Nits/editorial comments:
> 
> 
> ___
> Gen-art mailing list
> Gen-art@ietf.org
> https://www.ietf.org/mailman/listinfo/gen-art

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

[Gen-art] Gen-ART Last Call review of draft-ietf-v6ops-nat64-deployment-06

[Meral Shirazipour]

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-v6ops-nat64-deployment-06

Reviewer: Meral Shirazipour
Review Date: 2019-06-27
IETF LC End Date: 2019-06-28
IESG Telechat date: NA


Summary: This draft is ready to be published as Informational RFC .


Major issues:

Minor issues:

Nits/editorial comments:



Best Regards,
Meral
---
Meral Shirazipour
Ericsson Research
www.ericsson.com
___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

Re: [Gen-art] Genart last call review of draft-ietf-rtgwg-enterprise-pa-multihoming-08

[Alissa Cooper]

Pete, thank you for your review. I entered a DISCUSS ballot on the basis of 
your first point.

Alissa

> On Jun 4, 2019, at 11:41 AM, Pete Resnick via Datatracker  
> wrote:
> 
> Reviewer: Pete Resnick
> Review result: Almost 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 treat these comments just
> like any other last call comments.
> 
> For more information, please see the FAQ at
> 
> .
> 
> Document: draft-ietf-rtgwg-enterprise-pa-multihoming-08
> Reviewer: Pete Resnick
> Review Date: 2019-06-04
> IETF LC End Date: 2019-06-04
> IESG Telechat date: Not scheduled for a telechat
> 
> Summary: Almost Ready.
> 
> I found this overall to be an excellent document with clear technical
> explanations that even an upper-layer knucklehead like me could understand.
> However, there a couple of issues could use more discussion. I put them as
> "Minor issues", in that they're not showstoppers, but I do think they're
> important and hope you'll be able to address them.
> 
> Major issues:
> 
> None.
> 
> Minor issues:
> 
> Throughout, but particularly in section 5, this document refers to "hosts"
> doing address selection. To be fair, so does RFC 6724, but 6724 is referring 
> to
> *default* address selection. In reality, *applications* do address selection 
> on
> a host; the host stack will only do address selection if the application
> requests a default address. That works well for the scenarios in 6724, but in
> this document, for example section 5.2.3, I'm not so sure. The idea that a 
> host
> would receive an ICMP destination unreachable and re-arrange its address
> selection seems at least an incomplete picture: An application with a (normal,
> non-multi-path) TCP connection to a remote application is not able to "try
> another source address to reach the destination"; the source address is 
> already
> set for that TCP connection, so the only choice is to close the connection
> entirely. If the application chooses to re-establish the connection with a
> default address, yes, the host stack could then give a new default address 
> back
> to the application, but this is hardly the dynamic and quickly adjusting
> process that the document seems to be envisioning.
> 
> I don't think the above invalidates the core of the document or requires some
> grand rewrite. But I do think some clarification is in order, saying that the
> mechanisms described help with the *default* address selection, and some short
> discussion of the limitations for what applications can (and more importantly
> cannot) do with these mechanisms would be useful.
> 
> My suspicion is that section 7.3 underestimates the availability (current and
> future) of multipath transport. Apple is using it now in production, and Linux
> already has it in their implementation. I think this is actually a reasonable
> possible solution in the future, and I would be a little more optimistic than
> the WG in this section.
> 
> Nits/editorial comments:
> 
> Two editorial bits in section 1:
> 
>   This document defines routing requirements for enterprise multihoming
>   using provider-assigned IPv6 addresses.  We have made no attempt to
>   write these requirements in a manner that is agnostic to potential
>   solutions.  Instead, this document focuses on the following general
>   class of solutions.
> 
> Is that second sentence right? If you are giving a general class of solutions,
> that seems agnostic to the particular solution. Just a bit confusing.
> 
>   A host SHOULD be able respond dynamically...
> 
> Do you mean "is expected to" instead of "SHOULD"? "SHOULD" seems overdone.
> 
> ___
> Gen-art mailing list
> Gen-art@ietf.org
> https://www.ietf.org/mailman/listinfo/gen-art

___
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-regext-epp-fees-16

[Stewart Bryant via Datatracker]

Reviewer: Stewart Bryant
Review result: Ready with Issues

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-regext-epp-fees-16
Reviewer: Stewart Bryant
Review Date: 2019-06-27
IETF LC End Date: 2019-07-08
IESG Telechat date: Not scheduled for a telechat

Summary:

A well written document that is ready for publication subject to a couple of 
clarifications

Major issues: None

Minor issues:

===
2.  Migrating to Newer Versions of This Extension

   (Note to RFC Editor: remove this section before publication as an
   RFC.)

SB> This seems like good advice, why is it to be removed?
===

   Copyright (c) 2018 IETF Trust and the persons identified as authors
   of the code.  All rights reserved.

   Redistribution and use in source and binary forms, with or without
   modification, are permitted provided that the following conditions
   are met:

   o  Redistributions of source code must retain the above copyright
  notice, this list of conditions and the following disclaimer.
   o  Redistributions in binary form must reproduce the above copyright
  notice, this list of conditions and the following disclaimer in
  the documentation and/or other materials provided with the
  distribution.
   o  Neither the name of Internet Society, IETF or IETF Trust, nor the
  names of specific contributors, may be used to endorse or promote

SB> It is not clear what the purpose of this text is, whether or not it is 
SB> intended to be included with each instance the technical text below.
SB>If not why is the copyright not covered by the RFC boilerplate copyright 
text?

=
7.  Security Considerations

   The mapping extensions described in this document do not provide any
   security services beyond those described by EPP [RFC5730], the EPP
SB> "security services" or "security risks" 
=

Nits/editorial comments: None


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