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

From: "Wang,Weiming" <[email-masked]>
Date: Tue, 16 Apr 2013 08:11:42 +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: 

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

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,

  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

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

  > 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?
  >> >
  >> > I do hope authors can show your suggestions to solve the issue.
  >> 
  >> 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?
  > 
  > 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
  > 
  >> Since the AD has graciously offered to come up with some language, why
  >> 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
  > 
  >> >> 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.
  >> > 
  >> > 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.]
  > 
  > 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
  > 
  > 

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

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