In response to some questions that were not yet
answered in the below discussion
-----Original Message-----
From: <IETF-participant>
Sent: donderdag 23 januari 2003 1:04
To: Wijnen, Bert (Bert)
Cc: Scott Bradner
Subject: Re: [Fwd: quick review of the ason cr-ldp draft]
< snip >
My documented concerns are on the cr-ldp draft, there are a bunch of
things that are just documentation, but some other things
- the use of mpls for b-isdn (Kireeti called telephony)
Well, the fact that they use "call" terminology, does that really mean
that they are doing what you claim here?
this is tricky, I guess that you could claim they are not, but I was
deeply involved in some of the ISDN work, and it looks disturbingly
familiar. but you are right it needs to be proven that they don't, and
that has not been done
- use of non-IP addresses
I understand that we IP-biggots want everything in the whole world
to be IP based. But can we actually prescribe that to the world?
oh, but we have had it as an architectural principal that mpls follows
ip routing, it is even true when you have constraint based routed LSPs,
it is the routing protocol that describes the network
this wouldn't be an issue if they just were transferring non-IP addresses
across the cloud, but they talk about "Call Release message is sent by
any entity of the network" and it is not entirely clear that this is
the case.
Can the ITU folk answer this one please?
- UNI/NNI fuzziness
Is that a matter of cleaning up the text?
possibly - I'm through the better part of the OIF document
OK, eager to see where we get when you have read it all
Have you read the OIF spec(s)? Is it still fuzzy after that?
I also understand that most of the OIF UNI/NNI stuff has been worked
on by many (if not all) of the same people that are actibe in IETF.
Besides, a few years back, (I believe Rob Coltun was still RTG AD
and MPLS and such was all in RTG area), we (IETF) did send UNI folk
away stating that we did not want to work on it and so they did their
thing in OIF. The fact that most IETF-ers are participating there,
made me feel that they wanted it anyway, even though we in purists
land did not want to deal with it.
I believe OIF has approved UNI (and maybe also NNI, not sure) and that
vendors actually have products that comply with the UNI spec. I suspect
that they (these products) in fact already use the numbers that people
now ask IANA to assign. I know that such is a violation... but what
can we do?
we could at least understand what is going on and try to stop further
"damage" ;)
The damage has been done if they indeed have used such numbers in
any products. But I do know that OIF was using numbers out of the
LDP number space and RSVP number space a year or more ago, and I
just happened to run into one of their documents and then started
to reaise concerns. That then actually made bala send a I-D that
requested for assigments (I think he did so early 2002 or probably
already in 2001). It got delayed and delayed and revised and delayed
etc... And then OIF approved their UNI 1.0 in Oct 2001, so I would
be surprised if there are not yet already products on the market
that use those code-points they originally wanted.
Maybe Bala or someone else can react to this.
It is in fact also very interesting to see that some of the people
who now are objecting are on the contributors list of the OIF document:
John Drake
Kireeeti Kompella
But if you read the page 2 (contributors list) of the OIF document
then you see that many (like 10+ or so) of the major players in
our CCAMP and MPLS WGs were actually contributing to the OIF
LDP and RSVP specs for UNI.
- the level violation
do concern me quite a bit, if ITU go and do this the risk is high that
ldp starting to developing away from being an ietf protocol.
When we make things extensible, then that is always a risk. And how
do we control that.
Jerry Ash and John Drake sent as comments much to the same effect
during the last call.
But I think that Steve Trowbridge (and possibly others) refuted that
did they not? If it is indeed such a SERIOUS and BAD violation,
why not did MOST or ALL of the IETF-folk object and speak up, or
at least support the statements from Jerry and John?
I know why I didn't - part of this was outside my horizon and
it became visible only after I started to review it
Ok, but as I said above, many of our IETF folk were actively
participating in OIF... and I believe quite a few are also
active in ITU. So if it is such a technical issue, I would
have expected alarm bells to have gone off much much earlier.
If you ask me today I would object to let ITU go away and do this.
It is possible that some/most/all of the would go away if it were
better documented.
Well, did you read the ITU specs they pointed to?
nope -started with the OIF - since that was easier to find, the
ITU specs are on my list
Great, thanks for investing the time and doing a serious and
detailed review.
I do not believe that we MUST REQUIRE that all is documented in RFCs.
Are the ITU specs not clear enough?
Is Jerry Ash and others (who also participate in ITU) speaking up
there to BLOCK the achievement of CONSENT on thes documents?
You know, when people in ITU make trouble about our documents, we
often tell ITU: why don't you make your people participate in
IETF WGs and speak up there. We can do similar thing in the
otehr direction. Kireeti in fact mentioned that various ITU-goers
he knows claim that ITU does NOT have CONSENSUS on this. If this
is the case, then I guess there is no problem, cause those
people will then BLOCK the CONSENT in ITU, no?
well, I guess so - but I'm concerned about that IESG is about to
approve a document that are not up to the quality that
we've pushing on other authors, if I sent this to IESG - it would
have been bounced on the nits within 10 minutes
(note - the only informational document I've first hand experience
with is the documenation of the cr-ldp decission, but I've the
feeling that similar problems actually held that document until they
were taken care of)
I'm not counting on internal ITU politics to do our job
And we should not. That is why we did the IETF Last Call when it
turned out that they want assignments in the IETF-Consensus needed
name space.
Or are those ITU-goers a very small minority in ITU and are they
trying to do an end-run around the ITU process and trying to block
things by convincing us (IESG) to not approve assignment of
the reuqired numbers in RSVP and LDP namespaces?
have no idea - don't go to ITU, don't want to block good standards,
but want to have proper documents
We agree
I'm also a bit concerned with the statements on the possibility
to document after approval - seems to be a queer process, and not
something that I've seen before.
When technical changes are expected, then we should indeed not go
that path. When it is a matter of clarifications that we can
identify, then I have seen that happen many times, even at 48-hour
author-call from RFC-Editor.
so this is the formula you could use to do something along the lines
I proposed in an earlier mail
OK, there you suggested:
As Bert has demonstrated below thaer are things in at least the
cr-ldp draft that does not meet the (formal) critiera for be
an RFC.
All I know of now are some typos-type things that can be done
during editorial process.
I also know about the incorrect ref to the OIF document (see below)
we will fix that. When other people see more specific things, pls
point them out and be specific.
How would the IESG react to something like this?
- a statement that we understand the time constraints that ITU
are in and recognize that they need the code points
- inform the ITU that we are preparing a (g)mpls change process
- request that ITU submit their changes to the (g)mpls protocols
to us according this change process, in the same message inform
them that they will get their code points as requested
- a statement (in that same message) that this does not imply that
we are accepting changes to LDP or any other IETF protocol
by indirection
- a request to IANA to give ITU their code points
- inform other "potential (g)mpls protocol extenders" that we are
working on the change process
If this could be handled this way (or similar), it would work for me.
Otherwise I would object to approving the three drafts. Mostly based
on the fact that I don't understand where the LDP protocol are going.
Well, Scott and I have actually been talking with a few SUB-IP WG
chairs that we need to document something about (G)MPLS change process.
As a result of the ITU requests for assigments in RSVP namespace, we
also think that we probably need better and approved/published
IANA considerations/guidelines for RSVP paramter assignments.
Once we have that in-place, it seems obvious that we should tell
other people (organizations) what our (new or now documented) rules
are for making changes/ectensions/assignments. And of course we will
follow those in the future.
I am not sure it behooves us to now stall the ITU request and let them
wait till we get our act together. Not sure if that is what you meant?
As for rsvp I've not reviewed it carefully enough, but at least if
the use of non-IP addresses are in there I guess it should be a no.
They are. Funny thing here is that they ask for assignments mostly
in FCFS space (and the one or 2 code points that are not in FCFS
space could easily be moved into FCFS space), and so I do not see
how IANA (or we) can actually block/reject such assignments.
But just to point on the complexity here, the Bala and Lin drafts
includes normative references to
"OIF-UNI-01.0, User Network Interface (UNI) 1.0 Signaling
Specification"
that specification specifies at least one new LDP message (Status
Enquiry Message) and several TLVs. I'm not aware of that we have
approved those, they are not in the IANA registry.
Scott and I noticed that when evaluating over the last weekend.
Since the ASON CR-LDP doc that we Last Called indeed has a normative
reference to the bala document, and since it makes sub-assignments
udnerneath some of the code point of the bala document, it seemed
that we more-or-less did an implicit Last Call for the bala doc.
I can only speak for myself - and I was not aware of this - if for no
other reason the ason cr-ldp doc do not separate into normative and
non-normative references
Although I personally like it that even informational documents split
their normative and informative references, I normally leave it to
the RFC-Editor to push back when they come in as individual submissions
via the RFC-Editor, and that is what happened with these docs.
Now that the BALA doc is normative should be very clear, cause
the cr-ldp-extensions-for-ason doc does in fact use the Source ID TLV
and the Dest ID TLV (sections 3.1 and 3.2) as specified in ref 07
And ref 07 is the BALA document.
In any event, no one brought this up yet except you do at this point.
So we assumed that by having IETF consensus on the ASON CRLDP doc
we can defend that it also approves the bala doc. This is possibly
a trouble-some assumption... Scott and I understand that. And we
have presented the issue in similar wording to the IESG, so the
whole IESG is aware and can decide on this.
Do you see our reasoning as seriously flawed here?
you might get away with that reasoning, but I really would like it
out in the open, it would have been possible to last call all three
documents together
Well, with the posting of this discussion it is.
In fact Scott was going to post it anyway, but I suspect he has
not found the time yet.
If the IESG go about approving those drafts does this come to that
the LDP extensions in the normative references are approved?
See above. The answer is yes. the 3 docs:
draft-lin-ccamp-gmpls-ason-rsvpte-04.txt
draft-aboulmagd-ccamp-crldp-ason-ext-02.txt
draft-bala-uni-ldp-rsvp-extensions-04.txt
basically go together. They document (with ptrs to OIF and ITU docs
for details) the RSVP and CR-LDP code points requested for ASON
stuff. ITU has asked (cia a liason statement) back in May 2002
(I thijnk that was the month) that we review their docs and
approve the request to IANA for assignments.
this concerns me - how far do the indirection go? ptr to a doc with a
ptr to a doc with a ptr to a doc ....
I don't think it is any worse then when we use our own RFCs.
You should try to find something in our RFC-Series. Specifically
in the area of MPLS, GMPLS, CR-LDP and RSVP-TE... I know from
experiences that you keep getting pointed to yet more RFCs or
I-Ds all the time.
The tradeoff I think is that we want some RFC that documents where
we can find the details in the documents of the other organization.
We should not need to have them reproduce all the documents in
RFC-form.
was that liaison sent to SubIP, ccamp or the mpls wg?
I believe there where several, and they were to CCAMP mainly.
They are all accessible from the IETF web pages:
http://www.ietf.org/IESG/liaison.html
And ITU SG 15 has been giving ptrs and summaries at the last 4-5
CCAMP meetings at least.
The ason cr-ldp draft references the
B. Rajagopalan, User Network Interface (UNI) 1.0 Signaling
Specification, OIF-UNI-01.1, October 2001.
if this is not the (and it shouldn't if there is any meaning to the
OIF-UNI-01.0 vs. OIF-UNI-01.1 I can't find it on the OIF page, but I
guess that it will include the same extensions to LDP.
So it seems we need to clarify the exact reference. I am sending
then a question about this.
saw the answer - and it just strengthen the feeling I've on that the
ason cr-ldp is not very well thought through and reviewed
Right, The answer from the authors was that there is just one
spec and that is UNI 1.0. So this is a typo that needs fixing.
I guess I'm confused and in need of the (G)MPLS change process.
We should have had proper IANA Considerations for RSVP (which
would have caused an earlier IETF Last Call on the RSVP doc
which now passed without IETF Last Call) and indeed we should
have had proper "(G)MPLS change control documentation".
We cannot say that we have not seen this coming... ITU has been
working on this for more than a year. So I guess we have to
(at least partly) blame ourselves.
agreed - I should have reviewed the ITU work back in May
Bingo.
Thanks for your continued input and review. It is appreciated,
even though it causes us some trouble at this late time.
Main question I want answered from this email:
- if you read the OIF and ITU documents, does that more or less
make the stuff acceptable (let us say at least to the point
that things are properly documented).
So far I think the OIF document is pretty good as far as documentation
goes, but it contained stuff that I'm not entirely happy with
technically and that I was not aware of before this - part of the
problem is that it is not an open process that we can
influence, if the ITU docs are of the same quality that would be good,
but it would still leave the ason cr-ldp as severely sub-quality
But answer/reaction to all of my statements above would be helpful
too.
ok - I've tried :)
Thanks for trying. And we all appreciate the serious review you
are doing.
<IETF-participant>
Bert