Subject: RE: AD review of: draft-ietf-tewg-interas-mpls-te-req-06.txt (fwd )

From: "Wijnen, Bert (Bert)" <[email-masked]>
Date: Tue, 18 May 2004 10:19:31 +0200

W.r.t. my comments in item 7.
Section 6.1 says:

   6.1. Detailed Requirement Satisfactions

   The proposed solution SHOULD include at least all of the
   Application Scenarios presented in section 4 above. It MUST meet all
   the requirements described in section 5 each time a MUST is
   specified.

   If a solution can fulfill just a subset of those requirements in
   section 5, then it MUST be explicitly documented

To me the "SHOULD include" is already weak.
But specifically the last para/sentence makes the whole things
so darn weak... In my view, if you cannot fulfill the requirements, 
then you are just not meeting the requirements. Period.
It is just an example of how the document "discusses" a lot,
but is in my view pretty weak in being CLEAR as to what exactly
is a real requirement and what is not.

Hope this explains.
Bert 

> -----Original Message-----
> From: Jim Boyle [mailto:[email-masked]]
> Sent: dinsdag 18 mei 2004 5:08
> To: [email-masked]; [email-masked]; [email-masked]
> Cc: [email-masked]
> Subject: AD review of: 
> draft-ietf-tewg-interas-mpls-te-req-06.txt (fwd)
> 
> 
> 
> Raymond, JP,
> 
> Please see attached comments from AD during IESG review.
> 
> It appears that due to some process un-glitching - I am 
> responsible to 
> make sure you address all of these and update the draft! :)
> 
> Please let me know when you plan on having this completed, then I'll 
> review and bounce it back to the IESG.
> 
> A few clarifications...
> 
> (2) below refers to "Summary for Sub-IP related Internet Drafts"
> 
> On (7) below, I'm wondering if the focus of this is solely on 
> the last 
> sentence of section 6.1 (as it dillutes the requirements from 
> the previous 
> paragraph) ?  Bert - any clarifications would be appreciated.
> 
> thanks!
> 
> Jim
> 
> 
> ---------- Forwarded message ----------
> Date: Tue, 11 May 2004 15:52:23 +0200
> From: "Wijnen, Bert (Bert)" <[email-masked]>
> To: "Ed Kern (E-mail)" <[email-masked]>, "Jim Boyle (E-mail)" 
> <[email-masked]>
> Cc: "Alex Zinin (E-mail)" <[email-masked]>
> Subject: AD review of: draft-ietf-tewg-interas-mpls-te-req-06.txt
> 
> WG chairs, as you probably have seen, we are processing this
> as an experiment with new process:
> 
>    Participant in PROTO Team pilot:
>    Workgroup Chair Followup of AD Evaluation Comments
>    
http://www.ietf.org/internet-drafts/draft-ietf-proto-ad-comments-pilot-01.txt

So here we go with an initial set of comments. I am reading more and I am
asking OPS and RTG directorates for review.

1. ID-nits check:
   $ idnits-v1.24 <drafts/draft-ietf-tewg-interas-mpls-te-req-06.txt
   idnits 1.24, 16 Apr 2004, 07:05

   Line 479 contains non-ascii character in position 29.
   -->    network.  This allows SP1Æs customers connected to SP2 PE router to
                                  ^
   Line 488 contains non-ascii character in position 41.
   -->    TE LSP tail-end router located in SP1Æs network, as shown in the
                                              ^
2. Pls remove section: draft-ietf-tewg-interas-mpls-te-req-06.txt
   This makes no sense once it gets to "Publication requested" stage.

3. The use of RFC2119 language requires a normative ref to that doc.

4. Section 5.1.10.1 seems to require a writable MIB so that inter-AS TE
   tunnels can be configured (created. modified, deleted) via SNMP.
   It is OK with me... but are you sure that that is a hard requirement
   (MUST language is used) ?

5. Sect 5.1.12 and 5.1.13 use "SHOULD not" while I think "SHOULD NOT"
   is intended?

6. Lots of acronyms are used without being expanded the first time thye
   are used. 

7. Sect 6.1 .... MMM.... what does it really mean?
   It is so flexible, that ... oh well ...

8. End of sect 6.2 says:
      Other criteria might be added as this draft will evolve.
   while this draft is now "complete", no?

9. I worry about several normative references to pretty old I-Ds.
   Any outlook that those will indeed be approved at some point in
   time. Maybe several references are pretty old and need updating?   

Thanks,
Bert

---

From: "Wijnen, Bert (Bert)" <[email-masked]>
Date: Thu, 20 May 2004 14:31:06 +0200

> 
> Hi Bert,
> 
> I have clarified some in response to your first email 
> regarding this and repeat here again:
> "Wijnen, Bert (Bert)" <[email-masked]> wrote on 
> 05/18/2004 01:19:31 AM:
> 
> The wording in this section reflected results of many discussions on the list
> since different SPs may only need different sub-set of the requirements.  So we
> hve built some flexibility in the wording such that it would allow
> implementations to fullfill part of the requirements (so long as explicictly
> documented) and enable SP deployment to move forward sooner.  However it is
> stated that the implementation MUST meet those requirements a MUST is specified
> in the doc...
> 
This sounds like handwaving to me.
It sounds like: "operators cannot get to agreement on what the real 
and serious requirements are." And I then wonder....
what do the "SHOULD" requirements help us when developing the protocol
and solution? a "SHOULD allows people to NOT support or implement,
and so that may/will cause interoperability issues.
Specifically for INTER-AS (speifically if between multiple operators), 
this is bound to cause interoperability problems.

> This is pretty much similar for many of other discussions in 
> the draft.
> 
That is rather a nagetive statement instead of a positive statement.
We must be clear in what is REQUIRED, not list a whole lot of "Would Be Nice"
things. If you want to list such "Would Be Nice" things in an appendic
and state clearly that they are just a wishlist... then I can live
with it. But now it is a mix of everything, which (in my view) will make
it more difficult when it is time to decide on the protocol/solution.

Bert
> Regards,
> Raymond