Subject: [forces] AD review of draft-ietf-forces-interop

From: "Adrian Farrel" <[email-masked]>
Date: Thu, 11 Apr 2013 22:26:48 +0100

Hi authors of draft-ietf-forces-interop,

I have done my usual AD review of your document as part of processing
the publication request. The intention of the review is to catch issues
that might show up in IETF last call or IESG review and thereby
improve the efficiency of those review stages.

There are a few small issues that I would like you to address with a
new revision. As always, my comments are open for discussion and
disagreement.

I have placed the document into "Revised I-D Needed" state in the
datatracker until we resolve these small points.

Thanks for the work,
Adrian

---

I believe the intention of this work is to provide supplementary
information on top of that already contained in RFC 6053. In view of
that, you are correct to state that this document updates RFC 6053. To
achieve that smoothly you need to:

- Add a piece of metadata to the top of the file to read:

Updates: 6053 (if approved)

  (see http://datatracker.ietf.org/doc/draft-ietf-mpls-ldp-ipv6/ for an
   example)

- Explain the update in the Abstract. I'd suggest...

   RFC 6053 reported the results of the first ForCES interoperability
   test, and this document updates RFC 6053 by providing further
   interoperability results.

The additional context to the update that you give in the Introduction
is perfect.

---

I am worried by the references to two I-Ds. [I-D.ietf-forces-lfb-lib]
and [I-D.ietf-forces-ceha] were I-Ds at the time of testing.  There is
no law against this, but it gives us a problem:

The versions tested need to be pinned in time. For example, 
draft-ietf-forces-lfb-lib will probably be published as an RFC before
your document becomes an RFC, but it would not be correct to say that
you tested that RFC. So, I think you need some text talking about the
draft versions tested and giving specific name to the drafts rather than
just pointing at the citation.

I can probably help you draft some text here, but I think that it would 
be quickest for you to try to write down what you tested, and then I can
polish it.

---

The references are all to pot! idnits shows this up clearly and you need
to fix this before the draft can go forward.

(The uses of IP addresses flagged by idnits are OK and do not need to be
changed.)

---

The use of RFC 2119 language is a problem and needs to be fixed. 

You are not defining protocol behavior in this document and do not need
section 2.1 at all. 

Then you need to go through the document and clean up the upper case. If
you are making a direct quote from another RFC, then please make it much
clearer using indentation, quote marks, and by saying
   "As stated in [RFC1234]:"

If you are not quoting, then you really can use lower case. But please 
be careful even then. What would it mean to say "An implementation must
do this"? Would it really be the case that you mean: "We tested to see
whether an implementation does this as required in section 1.2 or 
[RFC1234]"?

---

I have a personal dislike of repeated definitions copied from other 
documents. They can cause all sorts of fun if you make a mistake when
you copy the text!  So I would prefer section 2.2. simply to point at 
the definitions from other RFCs.

However, I think this is a matter of style, and I do not insist that
you make this change.

---

Section 3.1 says:

   Some errata related to ForCES document were found by the
   interoperability test.  The errata has been reported to related IETF
   RFCs.

This is great. IMHO it is a more valuable outcome than the rest of the
work :-) If you can find a way to briefly list these or provide pointers
to the errata reports, I think this would be really nice and would help
validate all your hard work.

---

From: "Wang,Weiming" <[email-masked]>
Date: Fri, 12 Apr 2013 09:57:42 +0800

Hi AD, Shepherd, authoers, and all,

Please allow me to represent all authors to thank AD very much for the valuable review. Before we actually begin the revision, I'd like to give a quick response to some comments firstly. 

thanks,
Weiming

----- Original Message ----- 
From: "Adrian Farrel" <[email-masked]>

> The additional context to the update that you give in the Introduction
Yes,  clear enough to do.
> be quickest for you to try to write down what you tested, and then I can
I think this is the key issue raised. I agree well what AD suggest, i.e., to add a text to mention the issue, which may look like:  

    ......                                                     ....     The test involved several
   documents namely: ForCES protocol [RFC5810] , ForCES FE model
   [RFC5812] , ForCES TML [RFC5811] , ForCES LFB Library
   [RFC ????] and ForCES CE HA specification
   [I-D.ietf-forces-ceha].  Three independent ForCES implementations
   participated in the test.

   Note that, when the interoperability text happened, the ForCES LFB Library document [RFC ????] was still in progress of its internet-draft updates, and this test targets at v03 update of the document, which can be accessed at [.....]. The test to ForCES CE HA document targets at the internet-draft v00 [.....]. 

--------------
I now have more question that, if we should point out the deference between the tested version and the current version of the document? Or, shall we also mention what tested is still or not in existense in current version, or what change has happened? 

I do hope authors can show your suggestions to solve the issue.

> (The uses of IP addresses flagged by idnits are OK and do not need to be
Sure, thanks.
> However, I think this is a matter of style, and I do not insist that
Yes, I agree.  Ihe duplication of definitions is not always necessary especially for an informational RFC document. 

> validate all your hard work.
Sure, we authors will recall and check back the list and add text in the draft.

thanks again.
Weiming

> 
> _______________________________________________
> forces mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/forces

---

From: Jamal Hadi Salim <[email-masked]>
Date: Fri, 12 Apr 2013 08:53:23 -0400

I think we point to the RFCs, if they exist and mention specific versions
of the drafts pre-RFC. I am not sure if the xml will allow you to use obsoleted
documents as references; and if you reference them - whether they are
guaranteed
to be accessible when someone needs to reference them. Example, in 2 years
from now, will someone be able to access ceha draft version 3 on the ietf
web site?

Since the AD has graciously offered to come up with some language, why
dont we let him do that for us?

>> the definitions from other RFCs.

Agreed in this case.
In general I have the opposite taste ;-> I would rather have the
context in place
so i can correlate instead of going and reading some other doc elsewhere.
[Yes, one could make a mistake in copying. But also one could fix previously
erronous and provide more extended information such as the CEHA document
does when it provides context for HA derived from RFC 5810.]

cheers,
jamal

---

From: Joel <[email-masked]>
Date: Fri, 12 Apr 2013 08:56:30 -0400

Yes, we consider old versions of I-D's to be referencable for this sort 
of document.  They are sufficiently stable.  (Nothing is forever, but 
the current IETF operating policy is that all old versins remain 
accessible.)

Yours,
Joel

---

From: "Adrian Farrel" <[email-masked]>
Date: Sun, 14 Apr 2013 13:52:15 +0100

Hi all,

> > I now have more question that, if we should point out the deference
> > between the tested version and the current version of the document?
> > Or, shall we also mention what tested is still or not in existense in
> > current version, or what change has happened?
> >
> guaranteed to be accessible when someone needs to reference them. 
> Example, in 2 years from now, will someone be able to access ceha draft
> version 3 on the ietf web site?

I think it is really important to reference them. Like Joel says (and unlike
what the boilerplate says;-) I-ds seem to persist on the interweb for ever. You
shouldn't put them in as normative references, but you should put them in as
specific numbered and dated version. I would also recommend adding an RFC editor
note for each one as follows:

OLD
   [I-D.ietf-forces-ceha]
              Ogawa, K., Wang, W., Haleplidis, E., and J. Salim, "ForCES
              Intra-NE High Availability", draft-ietf-forces-ceha-05
              (work in progress), January 2013.

   [I-D.ietf-forces-lfb-lib]
              Wang, W., Haleplidis, E., Ogawa, K., Li, C., and J.
              Halpern, "ForCES Logical Function Block (LFB) Library",
              draft-ietf-forces-lfb-lib-10 (work in progress),
              January 2013.
NEW
   [I-D.ietf-forces-ceha-00]
              Ogawa, K., Wang, W., Haleplidis, E., and J. Salim, "ForCES
              Intra-NE High Availability", draft-ietf-forces-ceha-00,
              October 2010, work in progress.
              [RFC Editor Note. This reference is intended to indicate a
              specific version of an Internet-Draft that was used during
              interop testing. Please Do NOT update this reference to a 
              more recent version of the draft or to an RFC. Please
              remove this note before publication.]

   [I-D.ietf-forces-lfb-lib-03]
              Wang, W., Haleplidis, E., Ogawa, K., Li, C., and J.
              Halpern, "ForCES Logical Function Block (LFB) Library",
              draft-ietf-forces-lfb-lib-03, December 2010, work in 
              progress.
              
              [RFC Editor Note. This reference is intended to indicate a
              specific version of an Internet-Draft that was used during
              interop testing. Please Do NOT update this reference to a 
              more recent version of the draft or to an RFC. Please
              remove this note before publication.]
END

> dont we let him do that for us?

OK, here we go...

OLD   
   This document captures results of the second interoperability test of
   the Forwarding and Control Element Separation (ForCES) which took
   place February 24-25, 2011 in the Internet Technology Lab (ITL) of
   Zhejiang Gongshang University, China.  The test involved several
   documents namely: ForCES protocol [RFC5810] , ForCES FE model
   [RFC5812] , ForCES TML [RFC5811] , ForCES LFB Library
   [I-D.ietf-forces-lfb-lib] and ForCES CE HA specification
   [I-D.ietf-forces-ceha].  Three independent ForCES implementations
   participated in the test.
NEW
   This document captures results of the second interoperability test of
   the Forwarding and Control Element Separation (ForCES) which took
   place February 24-25, 2011 in the Internet Technology Lab (ITL) of
   Zhejiang Gongshang University, China.  The test involved protocol
   elements described in several documents namely: 

   - The ForCES protocol [RFC5810]
   - The ForCES Forwarding Element model [RFC5812]
   - The ForCES Transport Mapping Layer [RFC5811].
   
   The test also involved protocol elements described in the then-
   current versions of two Internet-Drafts.  Although these documents
   have subsequently been revised and advanced, it is important to 
   understand which versions of the work were used during this test.

   - ForCES Logical Function Block Library [I-D.ietf-forces-lfb-lib-03]
   - ForCES Intra-Network Element High Availability specification
     [I-D.ietf-forces-ceha-00].
   
   Three independent ForCES implementations participated in the test.
END

> context in place so i can correlate instead of going and reading 
> some other doc elsewhere.

Like I said, I'll let y'all decide what to do here since I don't feel strongly
enough.

Can I just note, however, that if you are "fixing" a definition that is already
in a published RFC, you are creating a nice little mess unless you also fix the
definition in the RFC. That fix could be through an Errata Report for a
typographical error, or by updating the published RFC. But simply publishing a
new RFC with a different definition is not a good idea.

And one other thing: Weiming's initial response didn't include any response to
my issues with RFC 2119 language.

Once again, thanks for all the work.

Cheers,
Adrian

---

From: "Wang,Weiming" <[email-masked]>
Date: Mon, 15 Apr 2013 20:16:59 +0800

Hi Adrian and all,

I think most of the issues raised by AD are been addressed and we are going to form a new 07 version very soon. The 07 beta version and a diff file to v06 in the attachment are for your review again.

thanks very much.
Weiming

---

From: "Weiming Wang" <[email-masked]>
Date: Tue, 16 Apr 2013 07:45:09 +0800

Hi Adrian and all,

I went back checked the process, it seems we reported several errata, but not actually accepted, which included: 

1. Section 7.1.1 (RFC 5810) part that says:
    *  When a table is referred to in the PATH (IDs) of a PATH-DATA-
         TLV, then the FULLDATA-TLV's "V" will contain that table's row
         content prefixed by its 32-bit index/subscript.  On the other
         hand, the PATH may contain an index pointing to a row in table;
         in such a case, the FULLDATA-TLV's "V" will only contain the
         content with the index in order to avoid ambiguity.

At the end of the text: "the FULLDATA-TLV's "V" will only contain the
content with the index ."
It should be "the FULLDATA-TLV's "V" will only contain the content without
the index ."

2. And also something of lesser importance. Page 109 (RFC 5810). For #5.
Says for Result:
OPER=SET-TLV
Should have been:
OPER=SET-RESPONSE-TLV

3.  There are several places in table 3 of rfc5810 where the text says "an component". 

As a result, we are not going to and the reports list in the document, rather, just keep the text: 

thanks,
Weiming

----- Original Message ----- 
  From: Wang,Weiming 
  To: [email-masked] ; 'Jamal Hadi Salim' 
  Cc: [email-masked] ; [email-masked] 
  Sent: Monday, April 15, 2013 8:16 PM
  Subject: Re: [forces] AD review of draft-ietf-forces-interop

  Hi Adrian and all,

  thanks very much.
  Weiming

  ----- Original Message ----- 

  > Once again, thanks for all the work.

------------------------------------------------------------------------------