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

> 
> Hi Bert,
> 
> I have clarified some in response to your first email 
> regarding this and repeat here again:
> "Wijnen, Bert (Bert)" <[email protected]> wrote on 
> 05/18/2004 01:19:31 AM:
> 
> > 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.
> 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
> > Hope this explains.
> > Bert
> 
> > > -----Original Message-----
> > > From: Jim Boyle [mailto:[email protected]]
> > > Sent: dinsdag 18 mei 2004 5:08
> > > To: [email protected]; [email protected]; [email protected]
> > > Cc: [email protected]
> > > 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 protected]>
> > > To: "Ed Kern (E-mail)" <[email protected]>, "Jim Boyle (E-mail)"
> > > <[email protected]>
> > > Cc: "Alex Zinin (E-mail)" <[email protected]>
> > > 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