RE: fatal flaw and RFC3474

["Ong, Lyndon" <LyOng@Ciena.com>]

Sounds like we're all in agreement!

I talked with one of the editors of 3474 at lunch and
it sounds like it started out as a simple document with
codepoint assignments but grew as different reviewers
suggested adding more information for explanation of
how the codepoints would be used...

Cheers,

Lyndon

-----Original Message-----
From: Lou Berger [mailto:lberger@movaz.com]
Sent: Wednesday, November 12, 2003 9:50 AM
To: Ong, Lyndon
Cc: 'Lou Berger'; Wijnen, Bert (Bert); Ccamp-wg (E-mail); Ong, Lyndon
Subject: RE: fatal flaw and RFC3474


Lyndon,

It sounds like you're agreeing with Bert, that we (the WG) needs to follow 
the formal liaison process.  This sounds reasonable to me.

Lou

PS I think the liaison process is independent of the proposed 3474 
update.  While you say 3474 represents an agreement with the IETF, the only 
thing that that was agreed to was code point assignment for an ITU 
recommendation.  Furthermore, 3474 is an informational document and cannot 
take precedence over documents approved by standard organizations.   The 
changes needed to G.7713.2 can be addressed via the liaison process that 
you and Bert mention.  This leaves the 3474 in it's current state where it 
doesn't match G.7713.2.  The proposed 3474 revision would correct this.

At 12:29 PM 11/12/2003, Ong, Lyndon wrote:
>Hi Lou,
>
>It sounds to me as if the reverse is the case, RFC 3474 represents the
>agreement between ITU and IETF on the assignment of codepoints but
>G.7713.2 is now slightly out of phase because the issue was not
>identified back to SG 15.
>
>I think Kireeti did in fact bring up the issue of ResvErr treatment
>at the ITU Rapporteur's meeting in Chicago, but at the time it was
>not clear that this was related to the "flaw".  If the
>people that brought up this issue can contribute details it can be
>addressed through ITU, maybe through an amendment.
>
>BTW, 3474 already references G.7713.2.
>
>Cheers,
>
>Lyndon
>
>
>
>-----Original Message-----
>From: Lou Berger [mailto:lberger@movaz.com]
>Sent: Wednesday, November 12, 2003 9:05 AM
>To: Wijnen, Bert (Bert)
>Cc: Ccamp-wg (E-mail)
>Subject: Re: fatal flaw and RFC3474
>
>
>Bert,
>          I think you make a good point.  While RFC3474 was positioned as
>"Documentation of IANA assignments" it is clearly more than that.   This
>leads to our current confusing state of affairs where we have to worry
>about standard GMPLS interworking with recommendation G.7713.2 as well as
>GMPLS interworking with the informational RFC 3474.  Others have made the
>point that 3474 = G.7713.2, but as you point out, this isn't the case.
>
>Given that the only ASON signaling documents that have standards
>organization standing is G.7713.x, what do you think about working on an
>RFC update that lists assignments and ether (a) references G7713.2 and
>omits any technical discussion or (b) incorporates G7713.2 verbatim?
>
>This will make it clear that we're focusing on G7713.2 support/interworking
>rather than on RFC3474.  Furthermore it'll clear up what document should be
>reference by the ongoing ASON support documents, i.e., G.7713.2.
>
>Lou
>
>At 11:35 AM 11/12/2003, Wijnen, Bert (Bert) wrote:
>
> >I hear that I may have caused confusion with my statement
> >in the ccamp session earlier this week.
> >
> >The "fatal flaw" was in this text in the I-D that became RFC3474
> >    Note that from the perspective of the ASON model ResvErr and ResvTear
> >    messages are not used.  For backwards compatibility, when an ASON-
> >    compliant GMPLS node receives either a ResvErr or ResvTear as a
> >    response during the setup phase of message exchange, the GMPLS-ASON
> >    node should instead issue a PathTear message downstream and a PathErr
> >    (with Path_State_Removed flag set) message upstream.  This is so that
> >    RSVP states are immediately removed upon error during the setup
> >    process.
> >That text has been removed after lots of discussions. So that "fatal flaw"
> >is not in RFC3464 itself. But it still exists in the ITU-T spec that this
> >RFC refers to. This RFC3474 is just the "supportive document for the
> >RSVP-TE assignments made by IANA". The base protocol spec is an ITU-T
> >doc (G7713.2) and that was not modified (and still has not been modified
> >as far as I know).
> >
> >My understanding was that CCAMP had send a liaison about this to ITU-RT SG15
> >but I cannot find it on our ietf web page with liaison statements.
> >
> >So Kireeti... was it send as liaison statement or was it communicated
> >otherwise. If the former, we must get it added to web pages at IETF,
> >if the latter, then I wonder if it should not become a formal communication.
> >
> >Appology if I was not clear at the meeting.
> >Bert