[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: mess re rsvp & ldp extensions
Mmmm... Scott, I am a bit suprised to see this at the IESG
list before checking with me... But OK.. that is where we
are.
If we go and redo this, then we should realize a few more
important things:
- the document draft-lin-ccamp-gmpls-ason-rsvpte-04.txt
that we approved back on december 12th, assigns RSVP
code points mostly in FCFS space, but also has a few
in (acoording to Bob Braden) IETF consensus space.
- the document draft-lin-ccamp-gmpls-ason-rsvpte-04.txt
implements RSVP codepoints for the same technology as
that behind draft-aboulmagd-ccamp-crldp-ason-ext-02.txt
- The draft-bala-uni-ldp-rsvp-extensions-04.txt doc
requests code points for OIF UNI 1.0, which was approved
back in Oct 2001, and to which MOST of our famous SUBIP
folk contributed. So why would they contribute if they
have a problem with it.
- A few folk indeed still keep bothering us with comments
but very few have real technical backing. It is indeed
mostly of the type: we do not like this.
- the person who (in my view) had the most reasonable
initial technical comment was Loa, but he gave it in
a private email to Scott, which I only saw after we
had recommended to IESG to approve. I also believe
that we have been interacting anough with Loa that
he can now live with the decision, and that he understands
that we (IETF) have been just bad in ignoring input
from the ITU folk.
Note: Loa did send comments private, cause it was sort
of conflicting with his recent employers viewpoint.
I have posted those to the public mailing lists as
received from <an IETF participant> so you have seen
most of it.
Scott, what makes you think we'll see an appeal?
Thanks,
Bert
> -----Original Message-----
> From: Scott Bradner [mailto:sob@harvard.edu]
> Sent: dinsdag 28 januari 2003 20:05
> To: iesg@ietf.org
> Subject: mess re rsvp & ldp extensions
>
>
>
> we (the IESG) OKed some ITU-driven IDs that defined expensions
> to RSVP & LDP recently
>
> as we talked about on the last IESG call we played a bit loose
> with process because we overlooked the fact that one of teh documents
> (draft-bala-uni-ldp-rsvp-extensions-04.txt) defined LDP
> extensions that
> were in the IETF consensus class and we did not do a last call
> on that document itself - we did a last call on
> draft-aboulmagd-ccamp-crldp-ason-ext-02.txt which has a normative
> reference to this doc and said that it was reasonable
> to think that the other last call thus could be said to include this
> doc - note that RFC 2434 does not actually require a IETF last call
> for "IETF Consensus" things - in fact it does not even suggest that
> an IETF last call could be done
>
> since the announcements on tehse docs there has been pushback
> in two areas
>
> 1/ that we did not do a specific last call on
> draft-bala-uni-ldp-rsvp-extensions-04.txt
>
> 2/ that we did not get IETF consus in *support* of
> draft-aboulmagd-ccamp-crldp-ason-ext-02.txt
>
> even though a last-call is not required for IETF Consensus values
> (maybe that is something that should get fixed - its kinda confusing
> now) I think that we should recind the approval of this ID and
> issue a last call - we will get an appeal if we do not and
> doing the last call revoves some of the assumed failure to
> follow process
> (even though we did follow process)
>
> problems:
> 1/ what do we do about the IANA assignments while the
> last call is happening - they have been written into (now)
> approved ITU documents
> 2/ what do we do if teh last call results in a consensus to
> not approve the assignments (which is what I sort of expect
> at this point since there has been such a fuss
>
> what do we do about draft-aboulmagd-ccamp-crldp-ason-ext?
> we generally do not get any significant comment on IETF last calls
> this ID brought in some comment (which I sent a note about a
> while ago)
> but not much until after we had approved it
>
> 1/ do we need to start insisting that we will not approve
> ietf-consensus IDs unless there is strong support on
> a Last Call ( if so, nothing in the last few years would
> have been OKed)
>
> 2/ many of the comments since the list I sent have been of the
> 'I do not like the way they did this' or 'the ITU
> is trying to pull a fast one' type - is that the
> kind of thing
> that should block an ID?
>
> part of the mess here is that we (the IETF) did not do a
> reasonable job
> of being responsive to messages from the ITU many months ago
>
> I think we should not unapprove draft-aboulmagd-ccamp-crldp-ason-ext
> but whatever way we go there will be a mess
>
> Scott
>