Re: [Pals] Document shepherd writeup for draft-ietf-pals-vccv-for-gal-03

"Andrew G. Malis" <agmalis@gmail.com> Mon, 23 March 2015 23:59 UTC

Return-Path: <agmalis@gmail.com>
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 435AF1A6FF2 for <pals@ietfa.amsl.com>; Mon, 23 Mar 2015 16:59:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] 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 22yVHfLFXyEc for <pals@ietfa.amsl.com>; Mon, 23 Mar 2015 16:59:21 -0700 (PDT)
Received: from mail-qg0-x233.google.com (mail-qg0-x233.google.com [IPv6:2607:f8b0:400d:c04::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B0D4C1A6F5D for <pals@ietf.org>; Mon, 23 Mar 2015 16:59:20 -0700 (PDT)
Received: by qgez102 with SMTP id z102so82672892qge.3 for <pals@ietf.org>; Mon, 23 Mar 2015 16:59:20 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=O0XKTHzH1RKTcwCFBOEvLdxavM86Dh5pbEawBW7Cf5s=; b=Cbdsp/SoqXXQ3V+EhvZnAfo1LU3yJjyqF2hYJr2gw8O8BRUuc9JMVHstZL7NqJxtgN LelbtS0RmjG38SgXoA9Lb32gxITdQzmfUK4K5RUdgTV3MAQil+V+D/OG7RIZQ7z4VZVm +6miNNhWX9SbnZy+8vUu/IIiKb3tDjkkVIZAfppVc0eRbF1jL8rdJaWHktzNTHvqPLsJ 2qFfmgsK5vZs/ALIehFhxPH5cNiU7mzjqqlNWk9+KKzeIdKYYYzd1f4tv47J972Zij1r mLpkJA3AoNNwKeEegrz0iCoO+54cYEmNKsU7hKGkb3IsHO3GjXTLbiuf5W+nn6Er3vL6 wl0Q==
X-Received: by 10.140.235.20 with SMTP id g20mr2433733qhc.32.1427155160019; Mon, 23 Mar 2015 16:59:20 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.140.104.170 with HTTP; Mon, 23 Mar 2015 16:58:59 -0700 (PDT)
In-Reply-To: <D133568D.75CC5%matthew.bocci@alcatel-lucent.com>
References: <D133568D.75CC5%matthew.bocci@alcatel-lucent.com>
From: "Andrew G. Malis" <agmalis@gmail.com>
Date: Mon, 23 Mar 2015 18:58:59 -0500
Message-ID: <CAA=duU0XUEcs_qsUqov2Q413BUSQ1mG3gVetr2sDCArecwmRgw@mail.gmail.com>
To: "pals@ietf.org" <pals@ietf.org>
Content-Type: multipart/alternative; boundary="001a1135cffc5a37a90511fd740b"
Archived-At: <http://mailarchive.ietf.org/arch/msg/pals/xWgvXRDiwAtbLR0svOyaAndeo_E>
Cc: Adrian Farrel <adrian@olddog.co.uk>, Stewart Bryant <stbryant@cisco.com>, "BRUNGARD, DEBORAH A (ATTLABS)" <db3546@att.com>, "Bocci, Matthew (Matthew)" <matthew.bocci@alcatel-lucent.com>
Subject: Re: [Pals] Document shepherd writeup for 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: Mon, 23 Mar 2015 23:59:25 -0000

Matthew,

Many thanks for the writeup.

PALS,

The draft was just submitted to the IESG for publication.

Cheers,
Andy

On Sat, Mar 21, 2015 at 12:10 PM, Bocci, Matthew (Matthew) <
matthew.bocci@alcatel-lucent.com> wrote:

>  Working Group,
>
>  I am the document shepherd for draft-ietf-pals-pals-vccv-for-gal-03.
>
>  Please find the document shepherd writeup below.
>
>  Regards
>
>  Matthew
>
>  ======
>  Document Shepherd Write-Up
>
>       draft-ietf-pals-vccv-for-gal-03.txt
>
>
>  (1) What type of RFC is being requested (BCP, Proposed Standard,
> Internet Standard, Informational, Experimental, or Historic)? Why is
> this the proper type of RFC? Is this type of RFC indicated in the title
> page header?
>
>  Standards Track.
>
>  This is appropriate since the draft defines the usage of the Generic
> Associated
> Channel Label (GAL) in a new context (a pseudowire signaled using tLDP)
> and also
>  makes additions to the VCCV channel type negotiation procedures defined
> in RFC5885
>  for the GAL, along with a new code point from the MPLS VCCV CC Types IANA
> registry,
>  which requires IETF consensus.
>
>  (2) The IESG approval announcement includes a Document Announcement
> Write-Up. Please provide such a Document Announcement Write-Up. Recent
> examples can be found in the "Action" announcements for approved
> documents. The approval announcement contains the following sections:
>
>  Technical Summary:
>
>     This document specifies a new Virtual Circuit Connectivity
>    Verification (VCCV) (RFC5085) control channel type for use with
>    pseudowires (PW) carried over an MPLS network.  This new channel type
>    uses the Generic Associated Channel Label (GAL) (RFC5586) to
>    distinguish VCCV packets from packets carrying user data. Although the
> use
>    of the GAL on PWs in MPLS-TP is defined in RFC6423, this draft
> specifies
>    the necessary extensions to VCCV to support the GAL on PWs setup and
> maintained
>    using targeted LDP (tLDP).
>
>
>  Working Group Summary:
>
>     There was nothing particularly unusual in the progress of the draft.
> The document
>    originated in the PWE3 working group and moved to the PALS working
> group when PWE3
>    was concluded in November 2014. The primary
>    debate in PWE3 was whether earlier control channel types (e.g. Router
> Alert) that do
>    not use the control word should be deprecated in favour of the use of
> the GAL. This
>    was resolved through the implementation survey described in RFC7079,
> which
>    showed that there were significant deployments of both pseudowires
>    using Router Alert or TTL expiry as the VCCV Channel Type. This draft
> therefore
>    does not deprecate other channel types, but rather provides a clear
> order of
>    precedence when more than one channel type is supported.
>
>  Document Quality:
>
>     There are multiple implementations of the GAL for MPLS-TP LSPs and
> PWs. Many
>    implementations of the LDP extensions for negotiating the use of the
> existing
>    VCCV control channel on a targeted LDP signalled PW are also known to
> exist.
>    The document has also been widely reviewed by the original authors of
> and
>    contributors to VCCV (RFC5085).
>
>
>  Personnel:
>
>     The Document Shepherd is Matthew Bocci (
> matthew.bocci@alcatel-lucent.com)
>    The Responsible Area Director is Deborah Brungard (db3546@att.com)
>
>
>  (3) Briefly describe the review of this document that was performed by
> the Document Shepherd. If this version of the document is not ready for
> publication, please explain why the document is being forwarded to the
> IESG.
>
>     I have reviewed the document several times during its development.
> There
>    are a couple of outstanding minor typographical errors that I have made
> the
>    authors aware of that I believe can be fixed at the next revision. The
> document
>    is ready to be forwarded to the IESG.
>
>  (4) Does the document Shepherd have any concerns about the depth or
> breadth of the reviews that have been performed?
>
>    No. The document has been reviewed many times by the PWE3 and received
> a number
>   of WG last call comments in PALS which were addressed by the authors.
>
> (5) Do portions of the document need review from a particular or from
> broader perspective, e.g., security, operational complexity, AAA, DNS,
> DHCP, XML, or internationalization? If so, describe the review that took
> place.
>
>     There are no parts of the draft that require further review or the
> help of a
>    MIB doctor.
>
> (6) Describe any specific concerns or issues that the Document Shepherd
> has with this document that the Responsible Area Director and/or the
> IESG should be aware of? For example, perhaps he or she is uncomfortable
> with certain parts of the document, or has concerns whether there really
> is a need for it. In any event, if the WG has discussed those issues and
> has indicated that it still wishes to advance the document, detail those
> concerns here.
>
>    I have no specific concerns.
>
>  (7) Has each author confirmed that any and all appropriate IPR
> disclosures required for full conformance with the provisions of BCP 78
> and BCP 79 have already been filed. If not, explain why?
>
>
>  An IPR poll was conducted in the PALs list. Each author responded that
> they
>  were not aware of any relevant IPR. There were no other responses.
>
>  (8) Has an IPR disclosure been filed that references this document? If
> so, summarize any WG discussion and conclusion regarding the IPR
> disclosures.
>
>     There are no IPR declarations against this draft.
>
>  (9) How solid is the WG consensus behind this document? Does it
> represent the strong concurrence of a few individuals, with others being
> silent, or does the WG as a whole understand and agree with it?
>
>    I believe the draft represents working group consensus. The document
> has
>   been reviewed many times by the PWE3 WG and received a number
>   of WG last call comments in PALS which were addressed by the authors.
> There
>   was considerable support shown for the draft during WG last call.
>
>  (10) Has anyone threatened an appeal or otherwise indicated extreme
> discontent? If so, please summarise the areas of conflict in separate
> email messages to the Responsible Area Director. (It should be in a
> separate email because this questionnaire is publicly available.)
>
>    None indicated.
>
>  (11) Identify any ID nits the Document Shepherd has found in this
> document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts
> Checklist). Boilerplate checks are not enough; this check needs to be
> thorough.
>
>     The document passes ID Nits. There are no relevant warnings.
>
>  (12) Describe how the document meets any required formal review
> criteria, such as the MIB Doctor, media type, and URI type reviews.
>
>     The document does not require any further formal review.
>
>  (13) Have all references within this document been identified as either
> normative or informative?
>
>     Yes. The references section is split into Normative and Informative
> sections.
>    These are appropriate.
>
>  (14) Are there normative references to documents that are not ready for
> advancement or are otherwise in an unclear state? If such normative
> references exist, what is the plan for their completion?
>
>     No. All normative references are to published RFCs.
>
>  (15) Are there downward normative references references (see RFC 3967)?
> If so, list these downward references to support the Area Director in
> the Last Call procedure.
>
>    There are no downward normative references.
>
>  (16) Will publication of this document change the status of any existing
> RFCs? Are those RFCs listed on the title page header, listed in the
> abstract, and discussed in the introduction? If the RFCs are not listed
> in the Abstract and Introduction, explain why, and point to the part of
> the document where the relationship of this document to the other RFCs
> is discussed. If this information is not in the document, explain why
> the WG considers it unnecessary.
>
>     This document does not make any changes to the status of existing
> RFCs. Note that
>    although the draft does add a channel type to VCCV, defined in RFC5085,
> it does
>    not deprecate or otherwise change the status of existing channel types
> defined in
>    RFC5085.
>
>  (17) Describe the Document Shepherd's review of the IANA considerations
> section, especially with regard to its consistency with the body of the
> document. Confirm that all protocol extensions that the document makes
> are associated with the appropriate reservations in IANA registries.
> Confirm that any referenced IANA registries have been clearly
> identified. Confirm that newly created IANA registries include a
> detailed specification of the initial contents for the registry, that
> allocations procedures for future registrations are defined, and a
> reasonable name for the new registry has been suggested (see RFC 5226).
>
>     The IANA considerations section is consistent with the body of the
> document.
>    there are two IANA requests, one for a new channel type code point and
> one
>    for a new LDP status code. The procedures for their use are specified
> in the body
>    of the document.
>
>  (18) List any new IANA registries that require Expert Review for future
> allocations. Provide any public guidance that the IESG would find useful
> in selecting the IANA Experts for these new registries.
>
>    There are no new IANA registries.
>
>
>  (19) Describe reviews and automated checks performed by the Document
> Shepherd to validate sections of the document written in a formal
> language, such as XML code, BNF rules, MIB definitions, etc.
>
>     There are no sections written in a formal language that would require
>    further checks.
>
>
>
> _______________________________________________
> Pals mailing list
> Pals@ietf.org
> https://www.ietf.org/mailman/listinfo/pals
>
>