[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Generic Textual Conventions



Hi -

> From: "Wijnen, Bert (Bert)" <bwijnen@lucent.com>
> To: "Harrington, David" <dbh@enterasys.com>; "Mreview (E-mail)" <mreview@ops.ietf.org>
> Cc: "Keith McCloghrie (E-mail)" <kzm@cisco.com>
> Sent: Tuesday, April 06, 2004 6:20 AM
> Subject: RE: Generic Textual Conventions
...
> If we were to do a generic TC MIB document that gets updated all the time,
> then it will stay at PS and so docs who import have a tough time to advance.
>
> So I thought... let us make then IANA-GENERIC-TC-MIB  items, which is
> (maybe a bit sneaky) bypass when it comes to normative references for
> DS and STD docs.
>
> Anyway, those were my considerations.
> We might also be able to do a BCP that we keep updating.
> I think that DS and STD can depend (normative) on a BCP.
>
> I bet some of you will say/think: STUPID CRLs...
> Oh well... we can continue to wait if NEWTRK will resolve any of this.
> I doubt it, but in any event it will take at least another year I suspect.
...

Back in CMIP land, we initially tried to put all the generic stuff in one place
(X.721 / IS 10165-2).  Even though the procedures there then were much
more streamlined than what we have here now, it proved to be too
unwieldy.  It was like trying to enhance a libary's usability by pasting all the
reference material into a single very large book.

Part of the problem is figuring out what is going to be "generic."  On the
one hand, deliberately making something generic may cause important
semantics to go undocumented.  On the other hand, a supposedly "generic"
TC may end up being slightly over-specified, making it unsuitable for
reuse.

Some of this problem would go away if TCs could be defined in terms
of other TCs, but that would also make the inter-document dependency
chains even worse.

If we were to do anything differently here, I'd favor putting obviously generic
TCs into separate modules and publishing them in relatively light-weight RFCs.
Something like what we did with RFC 2856 or 3705 comes to mind.

Randy