RE: Last Call: CR-LDP Extensions for ASON to Informational

["Wijnen, Bert (Bert)" <[e-mail]>]

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>