[bess] Rtgdir last call review of draft-ietf-bess-mvpn-expl-track-09

[Carlos Pignataro]

Reviewer: Carlos Pignataro
Review result: Has Nits

This is a very well written and detailed document.

I have only one concern, which I believe should be addressed before moving this
document forward:

I found the rational and specific details on what this document "Updates" from
three previous RFCs to be lacking, and confusing.

I recommend an "Updates from RFC XYZ" section in which there is a textual
explanation and ideally Old/New specifics on how this document updates previous
RFCs. At least, something more inline with current thinking as per
https://www.ietf.org/mail-archive/web/ietf/current/msg109106.html

Thanks,

Carlos Pignataro.

___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess

[bess] Opsdir last call review of draft-ietf-bess-l2l3-vpn-mcast-mib-16

[Mahesh Jethanandani]

Reviewer: Mahesh Jethanandani
Review result: Ready

{\rtf1\ansi\ansicpg1252\cocoartf1561\cocoasubrtf600
{\fonttbl\f0\fswiss\fcharset0 Helvetica;\f1\fmodern\fcharset0 Courier;}
{\colortbl;\red255\green255\blue255;\red0\green0\blue0;}
{\*\expandedcolortbl;;\cssrgb\c0\c0\c0;}
\margl1440\margr1440\vieww10800\viewh11640\viewkind0
\deftab720
\pard\pardeftab720\partightenfactor0

\f0\fs24 \cf0 \expnd0\expndtw0\kerning0
I have reviewed this document as part of the Operational
directorate\'92s\'a0ongoing effort to review all IETF documents being processed
by the IESG. \'a0These\'a0comments were written with the intent of improving
the operational\'a0aspects of the IETF drafts. Comments that are not addressed
in last call may be included in AD reviews during the IESG review. \'a0Document
editors and\'a0WG chairs should treat these comments just like any other last
call\'a0comments.\ \ Document reviewed:
\'a0draft-ietf-bess-l2l3-vpn-mcast-mib-16\ \ Summary: \ \ Ready\ \ Document
Abstract:\ \ \pard\pardeftab720\sl300\partightenfactor0 \cf2
\outl0\strokewidth0 \strokec2 This memo defines a portion of the Management
Information Base (MIB) for use with network management protocols in the
Internet community. In particular, it describes two MIB modules which will be
used by other MIB modules for monitoring and/or configuring Layer 2 and Layer 3
Virtual Private Networks that support multicast. \f1\fs26\fsmilli1 \
\pard\pardeftab720\partightenfactor0

\f0\fs24 \cf0 \outl0\strokewidth0 \
Comments:\
\
The document defines a MIB for use with network management protocols. Other
than whether the module is correct and useful or not, which I have little
expertise in determining, there are no operating or management considerations
that need to be discussed.}

___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess

Re: [bess] [Gen-art] Genart last call review of draft-ietf-bess-l2l3-vpn-mcast-mib-15

[Alissa Cooper]

Ines, thank you for your review. I have entered a No Objection ballot.

Alissa

> On Sep 2, 2018, at 4:33 PM, Ines Robles 
>  wrote:
> 
> Reviewer: Ines Robles
> 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-bess-l2l3-vpn-mcast-mib-15
> Reviewer: Ines Robles
> Review Date: 2018-09-02
> IETF LC End Date: 2018-09-03
> IESG Telechat date: Not scheduled for a telechat
> 
> Summary:
> I believe the draft is technically good. This document is well written and
> clear to understand.
> 
> This document defines a portion of the Management Information Base (MIB) for
> use with network management protocols in the Internet community. In 
> particular,
> it describes common managed objects used by other MIB modules which are
> designed for monitoring and/or configuring both Layer 2 and Layer 3 Virtual
> Private Networks (VPN) that support multicast.
> 
> Major issues: Not found
> 
> Minor issues: Not found
> 
> Nits/editorial comments: Not found
> 
> 
> ___
> Gen-art mailing list
> gen-...@ietf.org
> https://www.ietf.org/mailman/listinfo/gen-art

___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess

[bess] [Editorial Errata Reported] RFC8365 (5497)

[RFC Errata System]

The following errata report has been submitted for RFC8365,
"A Network Virtualization Overlay Solution Using Ethernet VPN (EVPN)".

--
You may review the report below and at:
http://www.rfc-editor.org/errata/eid5497

--
Type: Editorial
Reported by: Klemens Schragel 

Section: 5.1.3

Original Text
-
   list of encapsulation types defined in [RFC5512]; they are listed in
   Section 11.

   The MPLS encapsulation tunnel type, listed in Section 11, is needed

Corrected Text
--
   list of encapsulation types defined in [RFC5512]; they are listed in
   Section 12.

   The MPLS encapsulation tunnel type, listed in Section 12, is needed

Notes
-
Typo in the reference, Section 11 is "11.  Security Considerations", but text 
refers to "12.  IANA Considerations"

Instructions:
-
This erratum is currently posted as "Reported". If necessary, please
use "Reply All" to discuss whether it should be verified or
rejected. When a decision is reached, the verifying party  
can log in to change the status and edit the report, if necessary. 

--
RFC8365 (draft-ietf-bess-evpn-overlay-12)
--
Title   : A Network Virtualization Overlay Solution Using Ethernet 
VPN (EVPN)
Publication Date: March 2018
Author(s)   : A. Sajassi, Ed., J. Drake, Ed., N. Bitar, R. Shekhar, J. 
Uttaro, W. Henderickx
Category: PROPOSED STANDARD
Source  : BGP Enabled Services
Area: Routing
Stream  : IETF
Verifying Party : IESG

___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess

Re: [bess] Benjamin Kaduk's No Objection on draft-ietf-bess-mvpn-mib-11: (with COMMENT)

[Robert Raszuk]

Hi Benjamin,

> A general comment that we've been making on lots of documents in this
> space is that it would be nice to be in a place where the acronym "VPN"
> implies transport encryption.

Let me observe that for a lot of work in IETF term "VPN" does *not* imply
any form of either transport or payload encryption.

In fact here the MVPN which is derivative of L3VPNs do not imply use of any
encryption at all.

The term "VPN" here is really all about IP reachability separation.

So with this in mind can you please clarify your above comment ?

Kind regards,
Robert.


On Wed, Sep 12, 2018 at 3:49 AM, Benjamin Kaduk  wrote:

> Benjamin Kaduk has entered the following ballot position for
> draft-ietf-bess-mvpn-mib-11: No Objection
>
> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and CC lines. (Feel free to cut this
> introductory paragraph, however.)
>
>
> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
> for more information about IESG DISCUSS and COMMENT positions.
>
>
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-bess-mvpn-mib/
>
>
>
> --
> COMMENT:
> --
>
> A general comment that we've been making on lots of documents in this
> space is that it would be nice to be in a place where the acronym "VPN"
> implies transport encryption.  It's unclear that it's appropriate to
> request
> changes to this specific document toward that end, though.
>
> Perhaps I'm confused, but "mvpnAdvtPeerAddr" appears in the security
> considerations in the list of address-related objects that may have
> privacy/security impact.  That list is predicated on being "objects with a
> MAX-ACCESS other than not-accessible", but all the instances of
> mvpnAdvtPeerAddr I found in the body text were marked as not-accessible.
> Similarly for mvpnMrouteCmcastGroupAddr, mvpnMrouteCmcastSourceAddrs,
> mvpnMrouteNextHopGroupAddr, mvpnMrouteNextHopSourceAddrs, and
> mvpnMrouteNextHopAddr.  (Incidentally, why ar mvpnMrouteCmcastSourceAddrs
> and mvpnMrouteNextHopSourceAddrs plural with the final 's'?)
>
> Perhaps using subsections to separate the various tables' descriptions
> would aid readability.
>
>
> ___
> BESS mailing list
> BESS@ietf.org
> https://www.ietf.org/mailman/listinfo/bess
>
___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess