Re: [Gen-art] Gen-ART Telechat Call review of draft-ietf-dnsop-sutld-ps-07

[Ted Lemon]

On Jul 4, 2017, at 3:12 PM, Meral Shirazipour  
wrote:
> Note: I noticed lots of changes since LC review-I assumed they were all in 
> answer of the LC reviews.
> 

That’s correct. Thanks for the review!___
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-trill-arp-optimization-08

[Donald Eastlake]

Hi Dale,

Thanks for the review. See below.

On Wed, Jun 28, 2017 at 10:35 PM, Dale Worley  wrote:
> Reviewer: Dale Worley
> 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.
>
> Document:  draft-ietf-trill-arp-optimization-08
> Reviewer:  Dale R. Worley
> Review Date:  2017-06-28
> IETF LC End Date:  2017-06-29
> IESG Telechat date:  unknown
>
> Summary:
>
>This draft is basically ready for publication, but has nits
>that should be fixed before publication.
>
>Abstract
>
>This document describes mechanisms to optimize the ARP (Address
>Resolution Protocol) and ND (Neighbor Discovery) traffic in TRILL
>campus.
>
> s/in TRILL campus/in a TRILL campus/

OK.

> Perhaps summarize what the optimizations are:
>
>Each edge RBridge maintains a cache of IP/MAC address/Data Label
>bindings that are learned from ARP/ND requests and responses that
>pass through it.  This cache allows it to avoid flooding an ARP/ND
>request by either responding to it directly or by encapsulating it
>and unicasting it to the location where it is in use.

Wording along those lines sounds like a good addition.

>2 ARP/ND Optimization Requirement and Solution
>
>(including DHCP or gratuitous ARP_messages).
>
> s/_//

I think the underscore should be replaced by a space rather than the
null string.

>and should allow an end station to
>detect duplicate IP addresses.
>
> Unless this is a well-known phrase, it would be best if it was clear
> whether the end station is detecting that its own IP address is
> duplicated, or whether it is detecting that some other station's IP
> address is duplicated.

This is talking about the end station doing normal DAD by probing for
its own IP address.
"detect duplicate IP addresses" -> "detect duplication of its IP address".

>TRILL already provides an option to disable data-plane learning from
>the source MAC address of end-station frames on a per port basis (see
>Section 5.3 of [RFC6325]).
>
> Given how this section is written, shouldn't this option be considered
> an option to *enable* data-plane learning?  And in particular, doesn't
> that imply that TRILL already includes a solution to suppress ARP
> flooding?

By default RBridges learn the source MAC addresses of the Ethernet
frames they receive from attached end stations in a way similar to
such data plane learning by bridges. A change in that default, to not
learn such MAC addresses requires optional configuration. I don't
think just learning MAC addresses is useful for the types of ARP
flooding suppression talked about in this document.

> Also, what is the meaning of "learning from the source MAC address"?
> It seems like you'd want to specify what the learning is *of*, and
> then perhaps what it is learned *from*.
>
> Or is this particular learning of MAC addresses alone, and not of
> IP/MAC bindings?  If so, then isn't this feature orthogonal to ARP/ND
> optimization?

As per RFC 6325, RBridge default to data plane learning of MAC
addresses but not IP addresses. Although TRILL has ways of arbitrating
between conflicting addressing information learned through different
paths, it may be useful to disable data plane MAC address learning
when a directory is being used or the like.

> As a design matter, I'm curious why an RBridge can't learn IP/MAC
> bindings by snooping data packets, and only by snooping ARP packets.
> I suspect there are good reasons for it, but the naive reader (me) is
> left wondering...

You can get miscellaneous data packets at line speed so MAC address
learning is frequently implemented in hardware. While there is no
reason you couldn't do that for IP addresses, if you don't want to
require hardware changes from that in most existing implementations,
you would learn from ARP/ND in software which is generally practical
as they are not normally received that frequently.

>4.1 SEND Considerations
>
>Secure SEND messages require knowledge of cryptographic keys. Methods
>of communicating such keys to RBridges for use in SEND are beyond the
>scope of this document. Thus, using the optimizations in this
>document, RBridges do not attempt to construct SEND messages and are
>generally transparent to them. RBridges only construct ARP, RARP, or
>insecure ND messages, as appropriate.
>
> This doesn't flow quite correctly.  The second sentence suggests that
> there are known mechanisms for distributing keys to RBridges, but that
> this document doesn't describe them.

I disagree. Saying "X is beyond the scope of this document" means what
it says: that the topic is not further touched on in this document. I
do not think it implies that techniques to do X do or do not exist.

>

[Gen-art] Genart telechat review of draft-ietf-sipcore-content-id-07

[Elwyn Davies]

Reviewer: Elwyn Davies
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-sipcore-content-id-07
Reviewer: Elwyn Davies
Review Date: 2017-07-04
IETF LC End Date: 2017-06-27
IESG Telechat date: 2017-07-06

Summary:
Ready.  Thank you for addressing the comments in my last call review.

Major issues:

Minor issues:

Nits/editorial comments:
The references to RFC 5368 and RFC 6442 are informative rather than normative -
you don't need the details to implement this update.

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