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

From: Loa Andersson <[email-masked]>
Date: Mon, 18 May 2015 11:12:31 +0200

Hello,

I have been selected as the Routing Directorate reviewer for
draft-ietf-pals-vccv-for-gal. The Routing Directorate seeks to review
all routing or routing-related drafts as they pass through IETF last
call and IESG review, and sometimes on special request. The purpose of
the review is to provide assistance to the Routing ADs. For more
information about the Routing Directorate, please see
http://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir

Although these comments are primarily for the use of the Routing ADs,
it would be helpful if you could consider them along with any other
IETF Last Call comments that you receive, and strive to resolve them
through discussion or by updating the draft.

Document: draft-ietf-pals-vccv-for-gal-03.txt
  Reviewer: Loa Andersson
  Review Date: 2015-05-18
  IETF LC End Date: (I don't think that the IETF LC has started)
  Intended Status: Proposed Standard

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.

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.

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.

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

/Loa

-- 

Loa Andersson                        email: [email-masked]
Senior MPLS Expert                          [email-masked]
Huawei Technologies (consultant)     phone: +46 739 81 21 64

---

From: Stewart Bryant <[email-masked]>
Date: Tue, 26 May 2015 18:06:08 +0100

On 18/05/2015 10:12, Loa Andersson wrote:

Thank you for the review.
>   I've included that file for details.

Please see attached word file with comments on your comments
>   are forwarded on to the attachment circuit, but does not say anything

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.

>   I would want, it should be beefed up and clarified a bit.
Please see t he word file on the above.
>   -- expanding all abbreviations that is not on the RFC Editors
All dealt with

- Stewart

-- 
For corporate legal information go to:

http://www.cisco.com/web/about/doing_business/legal/cri/index.html

---

From: Loa Andersson <[email-masked]>
Date: Wed, 27 May 2015 08:51:35 +0200

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:
> _______________________________________________
> Pals mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/pals
>

--