Subject: Draft response to MFA liaison

From: "Adrian Farrel" <[email-masked]>
Date: Mon, 8 Oct 2007 19:42:46 +0100

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

---

From: "Andrew G. Malis" <[email-masked]>
Date: Tue, 9 Oct 2007 03:45:56 -0400

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

---

From: "Adrian Farrel" <[email-masked]>
Date: Mon, 15 Oct 2007 14:34:31 +0100

Thanks Andy,

I'll modify the wording of the liaison accordingly.

Wrt all the I-Ds, but especially the BFD work, I know you know that the IETF 
is contribution driven. If we all sit back and wait for the I-Ds to become 
RFCs, nothing will happen. So hopefully anyone waiting for something to 
complete will pitch in and help resolve any open issues.

But also, if the MFA is waiting for some specific work and is unsure of the 
status, a liaison will surely clarify the situation. And a liaison that 
makes a specific request for speed in a particular area may also get some 
attention.

Thanks,
Adrian
----- Original Message ----- 
From: "Andrew G. Malis" <[email-masked]>
To: "Adrian Farrel" <[email-masked]>
Cc: <[email-masked]>
Sent: Tuesday, October 09, 2007 8:45 AM
Subject: Re: Draft response to MFA liaison

>> The MFA sent us 
>> https://datatracker.ietf.org/documents/LIAISON/file487.txt