Re: Draft response to MFA liaison

"Andrew G. Malis" <agmalis@gmail.com> Tue, 09 October 2007 08:05 UTC

Return-path: <owner-ccamp@ops.ietf.org>
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IfA6I-0000Qg-Ng for ccamp-archive@ietf.org; Tue, 09 Oct 2007 04:05:58 -0400
Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IfA68-0005Us-F6 for ccamp-archive@ietf.org; Tue, 09 Oct 2007 04:05:54 -0400
Received: from majordom by psg.com with local (Exim 4.67 (FreeBSD)) (envelope-from <owner-ccamp@ops.ietf.org>) id 1If9n3-000JUW-3d for ccamp-data@psg.com; Tue, 09 Oct 2007 07:46:05 +0000
X-Spam-Checker-Version: SpamAssassin 3.2.1 (2007-05-02) on psg.com
X-Spam-Level:
X-Spam-Status: No, score=-2.5 required=5.0 tests=BAYES_00,RDNS_NONE autolearn=no version=3.2.1
Received: from [72.14.204.225] (helo=qb-out-0506.google.com) by psg.com with esmtp (Exim 4.67 (FreeBSD)) (envelope-from <agmalis@gmail.com>) id 1If9mw-000JT8-1n for ccamp@ops.ietf.org; Tue, 09 Oct 2007 07:46:04 +0000
Received: by qb-out-0506.google.com with SMTP id f11so1056462qba for <ccamp@ops.ietf.org>; Tue, 09 Oct 2007 00:45:57 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=O3dNBqtqvTGqIFz5Iq7XcGmLrH/KgHCuiZq9K+tOzYs=; b=WkjAuW7Wi3M04+Hqm2/VvgtxmS4MY/tWp/Phw9sHy7VQnPueCPYQngo+0MNvvPZXLFa0gUCc4UySKBTcsyPtjfFJF5y/MhkJUsHTRq+YoH7JKFR4UIsEN7xZhCpguzOC5Nxk7o5/0jW5k5P1gbpR3Kq/mpYO5iQgE3AewdBrrDw=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=N26duXqCOCnOTK9pNfuljEYiOGYjxYGR3G9KzClaaMmXK3/O3U+NoK0JPjIPuw7pMseKWdriu5fkLhQIdjgZ92NsmzGMAhhK9ryvvIJ75FhKQYTfV1iz4vY2NaE5ID8qxs6GR4wl35MVS+DnLTmlQWR/j4KjRW1n/gZ0JeAgYIs=
Received: by 10.65.100.14 with SMTP id c14mr23750845qbm.1191915956935; Tue, 09 Oct 2007 00:45:56 -0700 (PDT)
Received: by 10.65.234.18 with HTTP; Tue, 9 Oct 2007 00:45:56 -0700 (PDT)
Message-ID: <8c99930d0710090045ua30cc4hc7beaf426e1626f3@mail.gmail.com>
Date: Tue, 09 Oct 2007 03:45:56 -0400
From: "Andrew G. Malis" <agmalis@gmail.com>
To: Adrian Farrel <adrian@olddog.co.uk>
Subject: Re: Draft response to MFA liaison
Cc: ccamp@ops.ietf.org
In-Reply-To: <06d301c809db$09c8edf0$5102010a@your029b8cecfe>
MIME-Version: 1.0
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
References: <06d301c809db$09c8edf0$5102010a@your029b8cecfe>
Sender: owner-ccamp@ops.ietf.org
Precedence: bulk
X-Spam-Score: -4.0 (----)
X-Scan-Signature: 5011df3e2a27abcc044eaa15befcaa87

Adrian,

Thanks for your comments so far.  Regarding the references to drafts,
those of us in the MFA have been hoping that many of these will be
reaching the RFC editor's queue relatively soon.  If they get held up,
we'll have to decide on a case-by-case basis how important that draft
(and the functionality it supports) is to the specification, and
whether we we would be better to remove the reference or hold up the
work. Perhaps we could move the functionality in the drafts to a later
revision of the spec. We'll be discussing this at our next meeting.

This issue is a particular sore spot.  I'm very mystified in
particular as to what's been holding up the BFD specs.  Everyone is
implementing the expired drafts, but the limbo that the drafts are in
is affecting work both in the IETF and outside.

Cheers,
Andy

On 10/8/07, Adrian Farrel <adrian@olddog.co.uk> wrote:
> Hi,
>
> The MFA sent us https://datatracker.ietf.org/documents/LIAISON/file487.txt
> with an attachment that is their "straw-ballot" text of an MPLS
> Inter-Carrier Interconnect (MPLS-ICI) specification at
> https://datatracker.ietf.org/documents/LIAISON/file481.pdf.
>
> We were requested to respond by 18th October.
>
> Many of the contributors to the document are participants on this list, so
> it is my expectation that the level of comments may be low.
>
> I noticed a couple of issues reading the document and propose the following
> as a starting-point for a response liaison.
>
> Please send comments on what I have written and also any new ideas in time
> for me to send the liaison on October 15th.
>
> Thanks,
> Adrian
>
> ===
> Dear David and Rao,
>
> Thank you for sharing your MPLS-ICI specification during straw-ballot. As
> you will be aware, many of the contributors to your document also
> participate in the CCAMP working group, so the level of comments is
> understandably low.
>
> We do have the following observations for your consideration.
>
> 1. References.
>
> In your liaison to us dated 31st August 2007 you said: "In our
> specifications we are limited to referring only to documents
> that have been progressed to the RFC editor queue and beyond." Yet in this
> document you refer to several Internet-Drafts that have not reached this
> stage. It may be hoped that these drafts will progress before your final
> ballot.
> The following list of references falls into this category:
> - draft-ietf-ccamp-inter-domain-rsvp-te
> - draft-ietf-ccamp-inter-domain-pd-path-comp
> - draft-ietf-bfd-base
> - draft-ietf-bfd-v4v6-1hop
> - draft-ietf-mpls-bfd (you probably mean draft-ietf-bfd-mpls)
> - draft-ietf-idr-route-filter
> - draft-ietf-pwe3-ms-pw-requirements
> - draft-ietf-pwe3-pw-mib
> - draft-ietf-pwe3-pw-mpls-mib
> - draft-ietf-bfd-mib
>
> 2. Bidirectional Function at the ICI
>
> In the CNI spec you liaised to us before used GMPLS protocols, in particular
> to be able to support bidirectional services. Looking at the ICI
> specification it is unclear whether you intend to have this level of
> support.
>
> Looking at Annex D there is no reference to any protocol specification,
> although there is a reference to the CNI. Further the references table in
> section 5 does not reference RFC3473.
>
> Lastly, if it is your intention to support GMPLS signaling, you may also
> need to reference the GMPLS signaling MIB modules.
>
> 3. Broken Reference
>
> In D.2.3 you reference RFC3471 for RSVP-TE Graceful Restart. This is not the
> reference you intend. It is unclear whether you mean RFC3209, RFC3473, or
> draft-ietf-ccamp-rsvp-restart-ext, or possibly all of these.
>
> Best regards,
> Adrian Farrel and Deborah Brungard
> IETF CCAMP Working Group Co-Chairs
>
>
>
>