Re: [Pals] RtgDir review: draft-ietf-pals-vccv-for-gal-03

Loa Andersson <loa@pi.nu> Wed, 27 May 2015 06:51 UTC

Return-Path: <loa@pi.nu>
X-Original-To: pals@ietfa.amsl.com
Delivered-To: pals@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F11531A7022; Tue, 26 May 2015 23:51:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.91
X-Spam-Level:
X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5FdR16FerpFn; Tue, 26 May 2015 23:51:39 -0700 (PDT)
Received: from pipi.pi.nu (pipi.pi.nu [83.168.239.141]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 767771A70FD; Tue, 26 May 2015 23:51:38 -0700 (PDT)
Received: from [192.168.0.101] (81-236-221-144-no93.tbcn.telia.com [81.236.221.144]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: loa@pi.nu) by pipi.pi.nu (Postfix) with ESMTPSA id AA99B18016BD; Wed, 27 May 2015 08:51:36 +0200 (CEST)
Message-ID: <55656977.8020007@pi.nu>
Date: Wed, 27 May 2015 08:51:35 +0200
From: Loa Andersson <loa@pi.nu>
User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0
MIME-Version: 1.0
To: stbryant@cisco.com, draft-ietf-pals-vccv-for-gal.all@tools.ietf.org, "rtg-ads@tools.ietf.org" <rtg-ads@tools.ietf.org>
References: <5559ACFF.3080104@pi.nu> <5564A800.8050904@cisco.com>
In-Reply-To: <5564A800.8050904@cisco.com>
Content-Type: text/plain; charset="windows-1252"; format="flowed"
Content-Transfer-Encoding: 7bit
Archived-At: <http://mailarchive.ietf.org/arch/msg/pals/tqNHqhT5V3oEgcodu6d0GbpRGC8>
Cc: "rtg-dir@ietf.org" <rtg-dir@ietf.org>, "pals-chairs@tools.ietf.org" <pals-chairs@tools.ietf.org>, "pals@ietf.org" <pals@ietf.org>
Subject: Re: [Pals] RtgDir review: draft-ietf-pals-vccv-for-gal-03
X-BeenThere: pals@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "Pseudowire And LDP-enabled Services dicussion list." <pals.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/pals>, <mailto:pals-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/pals/>
List-Post: <mailto:pals@ietf.org>
List-Help: <mailto:pals-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/pals>, <mailto:pals-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 27 May 2015 06:51:42 -0000

Stewart,

Thanks for addressing my comments, with the exception of the comment on
the abstract, I'm comfortable with how this is don.

Abstract - I think you point at a generic problem. only 20 lines in
Abstract limits what you can say. However, there are documents that
succeed in writing very good Abstracts.

Also implying that "everyone that will read this document know what
the  GAL and VCCV is anyway" is kind of circular. If you find the
Abstract and does not get enough information from it is also unlikely
that you will read the document.

The function of the Abstract is described in section 4.3 of RFC 7322.
Among other things is says:

    "...the Abstract should be complete in itself.  It will appear
    in isolation in publication announcements and in the online index of
    RFCs."

Deborah,

This is now in your ball park, let me know if you have questions.

/Loa

On 2015-05-26 19:06, Stewart Bryant wrote:
> On 18/05/2015 10:12, Loa Andersson wrote:
>
> Thank you for the review.
>>
>> Summary:
>>
>> - This document is basically ready for publication, but has nits that
>>   should be considered prior to publication.
>>   Note: I also have a question about a security statement in the draft
>>   that I don't know if it has been addressed.
>>
>>
>> Comments:
>> - Overview of the draft quality and readability.
>>   The document is technically sound.
>>   The document is sometimes a bit hard to read, but I guess that
>>   will be sorted out by the RFC Editor.
>>
>>
>> - Anything else that you think will be helpful toward understanding
>>   your review.
>>   I normally do my reviews by Word with change bars and comments,
>>   I've included that file for details.
>
> Please see attached word file with comments on your comments
>>
>> Major Issues:
>> - I put the question on the security statement at the end of the
>>   second paragraph in the Introduction here. I'm not sure it is a
>>   major issue, but I want to lift to make sure that it is properly
>>   discussed.
>>
>>   If I understand correctly "..., and is a security risk" refers to the
>>   fact that OAM packets might be sent over the attachment circuit(s) if
>>   the TTL is not set right.
>>
>>   OAM packets on the attachment circuit as the specific problems this
>>   could involve is not listed as a security risk in 6073. The security
>>   section of 6073 talks about the possibilities that pay load packets
>>   are forwarded on to the attachment circuit, but does not say anything
>>   about OAM packets.
>
> The threat is called up in
>
>
>         13.1.1 <https://tools.ietf.org/html/rfc6073#section-13.1.1>.
>         VCCV Security Considerations
>
>
> of RFC 6073 which talks about VCCV i.e. OAM packets, however
> this text provides a new solution to the problem.
>
> I would like to hear from the ADs on whether this alternate
> mitigation to the TTL error warrants an update to RFC 6073
> being noted.
>
>
>>
>>
>> Minor Issues:
>> - I think I could say "No minor issues found" and say that everything
>>   else is nit, but since some of the thing captured in the word file
>>   are for clarity, e.g. the last paragraph in section 4 (fate sharing)
>>   and the first paragraph in section 5 (what MUST be inspected), so I
>>   guess that there are things that sits on the fence between minor and
>>   nits. However, I think that they are very easy to resolve, in that
>>   respect they can be treated as nits.
>> - A second minor issue is that I find the Abstract less informative than
>>   I would want, it should be beefed up and clarified a bit.
> Please see t he word file on the above.
>>
>> Nits:
>> - The rest of the comments in the word file are nits, e.g.:
>>
>>   -- Naming of the new channel (I think these to names refer to the
>>      same thing
>>      MPLS VCCV Control Channel (CC)
>>      GAL VCCV Control Channel Type
>>
>>   -- expanding abbreviations the first time they are used
>>
>>   -- expanding all abbreviations that is not on the RFC Editors
>>      list of well-known
> All dealt with
>
> - Stewart
>>
>> /Loa
>>
>
>
> --
> For corporate legal information go to:
>
> http://www.cisco.com/web/about/doing_business/legal/cri/index.html
>
>
>
> _______________________________________________
> Pals mailing list
> Pals@ietf.org
> https://www.ietf.org/mailman/listinfo/pals
>

-- 


Loa Andersson                        email: loa@mail01.huawei.com
Senior MPLS Expert                          loa@pi.nu
Huawei Technologies (consultant)     phone: +46 739 81 21 64