Subject: [Isis-wg] Another Comment on draft-ietf-isis-traffic-04.txt

From: David Hudek <[email-masked]>
Date: Tue, 29 Jan 2002 18:42:35 -0500

I have a comment/concern about the new TLV type 22 (Extended IS Reach),
regarding the reservation of subTLV types 250-254 for undocumented 
purposes by one particular vendor.

Putting in special set-asides to favor one particular vendor seems 
like a strange thing to do in an RFC... would it not be better to 
require documentation of these subTLVs' format and purpose, just as 
is done for the other types?  RFCs are supposed to promote multiple
inter-operable vendor implementations, and endorsing secret 
message components and behavior known only to one vendor
would seem counter to that goal...  Unless I'm missing something?? :-)

Thanks,
dave hudek
[email-masked]
_______________________________________________
Isis-wg mailing list  -  [email-masked]
http://external.juniper.net/mailman/listinfo/isis-wg

---

From: Tony Przygienda <[email-masked]>
Date: Tue, 29 Jan 2002 23:41:11 -0800

>would seem counter to that goal...  Unless I'm missing something?? :-)
I think you do, two aspects

    a) out of 255 very loosely populated space (it's only sub-TLVs) it's
        trivia to give 5 away. If space is congested, you can argue that
        vendors should do smarter things (e.g. one vendor as first thing
        is sticking their reserved MAC block into the TLV to make sure it's
        theirs and then they have a subtype so they can play games with
        a single TLV only). This is not a strong argument of course and
        if vendors start to play 'let's get some sub-TLV space just in case'
        we would be forced to have a discussion on a different plane of
        course.

    b) there will always be proprietary TLVs around, e.g. would you care
        to have Cisco IOS version encoded in a particular
        TLV documented? Probably not and if you do, Cisco may have good
        reasons to hide it since it's a pain to have customers asking why
        YOUR product does not work because YOU relied on their proprietary
        TLV they changed on the fly.
        I guess what I'm trying to say, proprietary TLVs will exist
        and it's better to know they are around rather than crash into them
        because of policy 'you have to tell us what the proprietary things
        contain' since guess what the reality will be? Nobody will tell you
        about them anymore.

    c) there will always be proprietary features around since vendors have
        to differentiate and it's especially hard with an open standard.
        If you don't believe it, try to get Dave K. to
        explain you everything he did in ISIS ever for the sake of it. I
        guess he won't be forthcoming or if he will, you probably won't be
        able to foot the bill he'll send you (I hope Dave bears the joke on
        his expense here ;-)

    thanks

    -- tony

---

From: Tony Li <[email-masked]>
Date: Wed, 30 Jan 2002 10:39:40 -0800

Dave,

We discussed this when we did it.

There is ample precedent for vendor-specified information in other
protocols (e.g., DHCP).  We also have opaque LSAs in OSPF.

In the short term, such code points allow for vendor experimentation and
innovation without operational disruption.

In the longer term, the vendor does not choose to interoperate with the rest of
us, that is their perogative.  And the marketplace is a fine mechanism for
insuring that the world knows that they are not interoperable.  I know,
I've been on the receiving end.  ;-)

Tony

David Hudek writes:
 | 
 | I have a comment/concern about the new TLV type 22 (Extended IS Reach),
 | regarding the reservation of subTLV types 250-254 for undocumented 
 | purposes by one particular vendor.
 | 
 | Putting in special set-asides to favor one particular vendor seems 
 | like a strange thing to do in an RFC... would it not be better to 
 | require documentation of these subTLVs' format and purpose, just as 
 | is done for the other types?  RFCs are supposed to promote multiple
 | inter-operable vendor implementations, and endorsing secret 
 | message components and behavior known only to one vendor
 | would seem counter to that goal...  Unless I'm missing something?? :-)
 | 
 | Thanks,
 | dave hudek
 | [email-masked]
 | _______________________________________________
 | Isis-wg mailing list  -  [email-masked]
 | http://external.juniper.net/mailman/listinfo/isis-wg
 | _______________________________________________
 | Isis-wg-external mailing list
 | [email-masked]
 | http://mailist.procket.com/mailman/listinfo/isis-wg-external
_______________________________________________
Isis-wg mailing list  -  [email-masked]
http://external.juniper.net/mailman/listinfo/isis-wg