Re: Draft response to MFA liaison

["Adrian Farrel" <[e-mail]>]

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" <[e-mail]>
To: "Adrian Farrel" <[e-mail]>
Cc: <[e-mail]>
Sent: Tuesday, October 09, 2007 8:45 AM
Subject: Re: Draft response to MFA liaison


> 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 <[e-mail]> 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
>>
>>
>>
>>
>