Subject: Re: Last Call: CR-LDP Extensions for ASON to Informational

From: Loa Andersson <[email-masked]>
Date: Fri, 24 Jan 2003 12:45:00 +0100

Bert,

my bad - what I meant was that the extensions in the normative
references would be ietf approved by indirection, when the
documents asking for code points were approved was not obvious
to people reviewing (at least it was not obvious to me,
not that anyone tried to run a secret process

and I'm concerned that the OIF has specified extension to LDP,
and preliminary allocated message names from the IETF concnsus space
more than a year ago and that this does not show in the IANA
registry yet. there are (I believe) implementations of the UNI spec
deployed.

/Loa

Wijnen, Bert (Bert) wrote:

>>loa> The consequence of approving the drafts will be that the 
>>extensions
>>loa> by OIF and ITU will be approved by the IETF. I'm not 
>>sure that this
>>loa> has been in the open.
>>
> 
> Two points:
> - the extensions to LDP were found to be in space that requires
>   IETF Consensus, and so Scott and I asked for an IETF Last Call
>   on the document. That is an explicit OPEN process

> Bert

-- 
Loa Andersson

Mobile          +46 739 81 21 64
Email           [email-masked]

---

From: "Wijnen, Bert (Bert)" <[email-masked]>
Date: Fri, 24 Jan 2003 12:40:48 +0100

.. snip ..

> steve> To hear now that someone thinks that the ASON work in 
> ITU-T is some kind
> steve> of secret end-run around IETF, and not involved with 
> or related to the
> steve> work being done internally in IETF is absurd. At every 
> stage of the work,
> steve> IETF was kept informed of the work and invited to 
> participate. At the
> steve> invitation for help to address the additional ITU-T 
> requirements, there
> steve> was no response. As ITU-T progressed this work and 
> invited further comments
> steve> and alignment of the base GMPLS protocols, again no 
> response. And to the
> steve> final pleas for comments and codepoint assignments, no 
> response.
> steve> ...
> steve> After some private communication with the Area 
> directors, we received some
> steve> advice that one tool that might be used to finally get 
> the IANA codepoint
> steve> assignment complete would be to publish what we were 
> doing in ITU-T as
> steve> informational RFCs. This is the stage we are at today, 
> and given the
> steve> history I describe above, I do not think anybody can 
> say that we are
> steve> at this point because any of us did not do everything 
> possible to
> steve> do this work (a) in IETF, with the initial 
> communication of requirements;
> steve> or (b) in cooperation between ITU-T and IETF, once 
> this work had
> steve> progressed in ITU-T.
> steve> 
> steve> But this is all water under the bridge. We are at the 
> point of trying
> steve> to get some codepoints assigned for ITU-T documents we 
> are trying to
> steve> complete. Nobody should say "no" at this point because 
> they think we
> steve> didn't try to work this IN or WITH IETF first. It 
> should be clear to
> steve> all that this is not the case.
> 
> I can understand the frustration in not getting cooperation 
> and follow-up on the ITU/ASON requirements.  However, the 
> 'private communication with ADs' left most of us in the dark 
> as to what was (is) going on.  
> 

Jerry, there is nothing secret on this private communication here.
What Steve is saying is that the ITU people had been sending
emails to IANA to ask for RSVP and LDP code point assignments.
And that did not go smooth. So they asked teh ADs if we could
motivate IANA to take action. That is where we suggested to
write an individual I-D for publication as informational
RFC and to submit that to the RFC-Editor. That way one
achives two things:
- a timer starts ticking on the request to publish I-D as RFC
- RFC-Editor and IANA have documented material to review
  the request

> The concern still is (drawing from posts by Loa Andersson and 
> David Charlap):
> 
Two points:
- the extensions to LDP were found to be in space that requires
  IETF Consensus, and so Scott and I asked for an IETF Last Call
  on the document. That is an explicit OPEN process
- the extensions to RSVP are mainly in FCFS space and in such 
  space the IANA can actually assign without any public
  documentation. However IANA decided to ask for documentation
  (and that got supported by teh ADs as per above) and so 
  Zhi and Bala submitted I-Ds. Thes I-Ds have been around
  in various versions for quite a while, and the Zhi document
  was actually discussed in CCAMP meeting a few times, so 
  I do not think it is fair to question if this was possibly
  done in the dark (or closed) rooms.

... snip 

Bert

---

From: Yakov Rekhter <[email-masked]>
Date: Fri, 24 Jan 2003 07:35:53 -0800

Bert,

[clipped...]

>   on the document. That is an explicit OPEN process

Quoting from the e-mail you sent recently:

  If not enough people (and 10 is the absolute minumum, but having seen
  the attendence of TWEG sessions, I'd expect 25 or more) can speak up
  to state one of:
  
   - I read it and I am positive, it is good stuff
   - I read it and I see no problems or objections
   - I read it but I cannot determine if it is bad, but I can see that
     what has been discussed in the WG is indeed in the document
   - I read it and I have these nits/objections...
   - I did not read it cause this is not relevant to my xxx job/work/function
   - I did not read it cause I think this is nonsense 
  
  Then I get the feeling that we're just allowing a small group of
  people push their petty-project through the process. That seems NOT
  good to me. We need serious WG participation in reading and commenting
  in one of these forums above, before we can declare that we have WG
  consensus on a document to be presented to IESG for approval as RFC
  (in whatever form).

Since (as you said) the extensions required IETF consensus, and
with the above in mind could you please share with the rest of
us the information on how many people spoke up about the draft
to state one of:

   - I read it and I am positive, it is good stuff
   - I read it and I see no problems or objections
   - I read it but I cannot determine if it is bad, but I can see that
     what has been discussed in the WG is indeed in the document
   - I read it and I have these nits/objections...
   - I did not read it cause this is not relevant to my xxx job/work/function
   - I did not read it cause I think this is nonsense

Yakov.