Re: Moving right along ...

[Zhi-Wei Lin <zwlin@lucent.com>]

Hi Kireeti, all,

Kireeti Kompella wrote:
> 
> Hi Zhi,
> 
> > -- cr-ldp is in version 4, which means that the revisions done to
> > rsvp-te05 has not been reflected there...how do we resolve this
> > inconsistency?
> 
> Would bumping the version number of the cr ldp draft work for you? :-)
> 
> I see that Don has posted a new version -- thanks, Don.
> 

<z> :-) thanks. In that case, I assume that the -05 version is now that
one going for IESG last call.

Incidentally, what is the procedure for the length of time for last
call? I hope you do realize that there are many people who are involved
with this who are attending a SG 15 ITU meeting this and next week, and
therefore do not have time. I would request that the last call deadline
be extended to the end of the month, as many of the major individual
players are currently tied down...
</z>

> > -- rsvp-te-05 and signaling-06 has incorporated the restart capability
> > as proposed by Ping Pan. However, that work was never looked at
> > carefully and some issues remain on how this covers all the different
> > cases.
> 
> "that work was never looked at carefully" is a strong statement.
> The work *was* looked at carefully, at least by some folks.  There
> may well be corner cases that have been missed; it would be an
> excellent idea to point those out.
> 

<z>Yes, I agree it is a strong statement. But I think it's warranted.
Yes, it solves a problem, but there are many differnet solutions of
which Yangguang mentioned one such. Who made these decisions to include?
Is there a need to look at both these (and possibly other) methods first
prior to including in a WG document? IETF is a public standards forum
where discussions on what is chosen is done in public for everyone's
benefit, and therefore this decision should be considered by everyone
prior to adding anything...</z>

> > Is it correct to simply include content of individual drafts into
> > a WG draft that is in last call without adequate data on whether it
> > handles all the different cases?
> 
> Clearly not.  Are you suggesting that that was what was done?
> 
> It is a judgment call to include significant new material into a
> document in last call.  In this instance, handling restart of the
> control plane is of sufficient importance to warrant inclusion.
> That said, this inclusion happened some time ago (late July);
> your comment would have been more timely then.
> 
> In any case, it would be more helpful if you pointed out
> scenarios that are missing, and even better if you had concrete
> suggestions to fix things.
> 

<z>I think Yangguang mentioned some. If you look back at the email
archive, I think some folks from Netplane and others also made some
comments. And yes, these comments were made when the resync stuff was
first added. The comments were simply not addressed adequately (in my
opinion of course).</z>

> > -- signaling-06 also includes several new items in there that doesn't
> > seem to be added because of a identified need (do a diff to find the
> > differences). Why were they added to the document (I'm not questioning
> > them, just asking for clarifying explanation)?
> 
> Good question, but rather open-ended.  Can you mention a few
> specific items?  At that point, Lou et al could mail the list
> with answers.
> 

<z>As I said, that is easily seen by simply diff'ing the two versions.
One is RR object. Again, I think I understand the reason for it, but
this addition was never discussed in an open forum where everyone can
make a decision. It would be useful (for my education) if I can hear
what the reasons were for adding (why this is needed to support some
requirements), and see if everyone agrees to this...</z>

> > -- in signaling-06, since we've decided that this set of I-Ds are to be
> > consistent with the standards for the respective technologies, then
> > "Digital Wrapper, G.709" should be changed to "ODUk, G.709" or something
> > that is used in G.709 or G.872 to describe the types of the signals...
> 
> I like being consistent with G.709/872.  Eric, Dimitri, others:
> comments on terminology?
> 

<z>Thanks</z>

> > -- There are still some technical questions remaining on some content of
> > the sonet-sdh-02 that are still been discussed in a private list (my
> > understanding). Shouldn't these be resolved first before it goes for
> > last call?
> 
> Can you take them up with the authors?
> 
> As a general comment, the operative phrase at the IETF is
> "rough consensus".  It would be ideal to have all comments
> addressed, and all issues resolved, but there is a point at
> which we have to declare that the remaining issues/comments
> are not significant enough to halt progress.
> 

<z>Yes, I agree with "rough consensus" (in a way), but if things that
are added are unclear or doesn't seem to address any requirements, and
the private discussions are just that: a private discussion. I would
think that the authors need to have these discussions in the open to get
as much participation and "buy-in" as possible.

For example, I've commented on the "switching type" as part of signaling
for some time, and never really understand why this was added. Yes,
there has been some explanations, but I don't think those are reasons
for adding. It sounds like it is something that "seems" to be
reasonable. If something can be added because it "seems" reasonable,
then does that mean if I think there is something that "seems"
reasonable, the authors would be compelled to add these or who makes the
decision to add these?

Of course, Juergen has provided some examples of issues as well, so
those still need to be resolved. And I believe they need to be resolved
in the open public email list so that everyone understand the decisions.
Let's open up the commenting and decision process to the "common folks"
like myself! 
</z>

> > -- in sonet-sdh-extension-00, we would like to add two new flags into
> > the list of flags for transparency (I have spoken to Eric already, and
> > I'm waiting to have these added in the next version):
> >       flag 13: M0
> >       flag 14: M1
> 
> I don't believe that that should be an issue; however, can you offer
> reasons for their inclusion, just so we know?
> 

<z>My understanding is if someone uses this, then it can be included.
Therefore the reason is that some company uses it. Hope this is reason
enough!</z>

> > -- I believe g709-00 is currently undergoing some changes to align with
> > standards positions and to reflect the work on OTN TDM that is been
> > discussed in ITU study group 15 meeting this week and next week.
> 
> Excellent!
> 
> Kireeti.