As you may all know, when an IETF Last Call is issued,
people can send comments to IETF and/or IESG mailing lists.
Here is a comment (with some back and forth discussionbs)
that was only sent to Scott Bradner and myself, but that
deserves publicity. It is from a constructive and conscientious
participant in the IETF in the Sub_IP area. For various
reasons, the person does not want to go public him/herself.
So I am forwarding without revealing the originators name.
Bert
-----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]
Bert,
Wijnen, Bert (Bert) wrote:
< snip >
Last weekend, Scott and I evaluated the comments and documents and
based on that we recommended to IESG that approval seemed OK.
We also informed ITU SG15 that we made a positive recomendation
(they need the assignments this week), but that IESG still had
to decide in their upcoming telechat.
So if we have to retract based in this continued discussion, that
looks ugly. But we have to do what needs to be done.
< snip >
Also... not having these comments in the open, does not show to
ITU people (or anyone) who is following the Last Call that this
is happening and what the arguments are.
Possibly Scott or I should post this to ietf list as coming from
an anonymous commenter. So that at least the issues are on the table.
I guess that is OK
< 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
- UNI/NNI fuzziness
Is that a matter of cleaning up th text?
possibly - I'm through the better part of the OIF document
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 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
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
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
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
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
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
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
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 ....
was that liaison sent to SubIP, ccamp or the mpls wg?
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
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
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 :)
<IETF-participant>