Re: [Teas] WG Last Call on draft-ietf-teas-gmpls-scsi

["Adrian Farrel" <[e-mail]>]

Hi and thanks.

> How about:
> 
> "The ISCD is defined in [RFC4203] and [RFC5307]. It can include a Generalized SCSI
> when advertising technologies whose Switching Capability definition reference
> this document.  The corollary of this is that the  Generalized SCSI MUST NOT be
> used for ISCDs of technologies whose Switching Capability definition do not
> reference this document."

Yes.
 
> > Will you not pre-populate the registry with the TLVs from one of 7138
> > and 7688? Although you can't pull them both into line (because of the
> > Type value overlap) you could make one of them consistent.
> 
> I'm not sure I get this one. The idea is not to use the Generalized SCSI for them,
> they already have their own TLVs and registries linked to the Switching Type.

Well, OK.  And flexigrid is doing its own thing.
Makes me wonder whether there are any switching types left to make use of this document :-Z

> > I think Section 6 could be clearer...
>>
> > But, I don't think this is going to work!
> > Suppose I define a new TLV for the foo-switch technology. Obviously it
> > comes from the 1-32768 range.
> > But the next day someone dreams up the foo-prime (commonly known as
> > bar) technology and wants to use the same TLV.
> > Can't do it.
> 
> I don't get this either (and It's only Thursday...). Foo would get value 1 allocated
> and bar value 2 if they are both specific technologies, otherwise Foo would get
> value 1 allocated and Bar would get 32768 allocated ... I don't get the issue.

Foo and Bar are technologies. They don't get TLVs.
But for Foo we want the "Fridge-temperature" TLV so we assign value 1 for that TLV. We genuinely believe that only Foo will ever care about the temperature of the fridge.
Now, along comes Bar. Bar also wants to know the temperature of the fridge and would like to simply use the same TLV. But it is allowed. So a new TLV must be assigned from the registry (presumably 2).
Oh wait, here is the Humbug switching technology, that *also* cares about fridge temperatures.

See my point?

> > I suggest you should go to a single range and "'Any' or a list of
> > values from IANA's Switching Types registry".
> >
> > (In any case, I don't believe you benefit from the current split.)
> 
> Even if I don't get the issue I don't have any strong opinion (neither does Lou, we
> put this as an open question to the WG and we didn't receive many feedbacks)

Oh, but that is probably because no one really cares about this work!

> For me it's ok to have a single range.

Then let's do it and you don't even need to understand my point to make me happy ;-)

> > In section 6
> >
> >    The registry should be established with registration policies of
> >    "Standards Action" for Standards Track documents, and "Specification
> >    Required" for other documents, see [RFC5226].  The designated expert
> >    is any current TEAS WG chair.
> >
> > I think this is more words than you need and is convoluted!
> > You are saying that "Values are assigned only for Standards Track RFCs
> > approved by the IESG except when the document that requests the
> > assignment is not a Standards Track RFC".
> >
> > Now, you know that all Standards Track RFCs will go for approval by the IESG.
> > That will happen regardless of what you write here.
> >
> > So you can just say "Specification Required" and cover all of the bases.
> >
> IN what is this different from the OTN Signal Type Register:
> (https://www.iana.org/assignments/gmpls-sig-parameters/gmpls-sig-
> parameters.xhtml#otn-signal-types ) where we have both registration
> procedures allowed? At that time the experts where appointed by the AD, not
> the draft, that's correct.

It's odd...
7139 says
   New values are to be assigned via Standards Action as defined in
   [RFC5226].
It was 7892 that caused the update.

I recall some debate as that went through, but I cannot recall why I didn't argue then. Probably I was too old (actually, I raised the issue as AD shortly after WG adoption, but seem to have not picked it up as an individual at WG last call).
Looks like the IESG also had a go at that text for some reason.
Looks like before that your AD (Deborah) was worried about the overlap.

Anyway, I probably don't care, but I don't see why Specification Required isn't enough. Go have a look at 5226.

> > That just leaves three things:
> > 1. You need to document in this I-D the advice for the DE. When should
> >    she grant assignment and when not? What should she watch out for?
> > 2. I know there are plenty of code points in your new registry, and I
> >    know that we would like GMPLS to be widely used, but do you *really*
> >    want to allow assignments for anyone who publishes a spec? Even if
> >    that spec conflicts or competes with IETF standards? Or maybe that
> >    is what you expect the DEs to police?
> > 3. The DEs serve at the pleasure of the IESG and cannot be appointed in
> >    an I-D. Just leave that bit out and let the AD deal with it.
> 
> We have a precedent in CCAMP when we decided to nominate to experts (the
> co-chairs) that are allowed to ask for the allocation of codepoints for non
> standard track documents (i.e. RFC7963).
> Is this case different?

The precedent applies to Specification Required spaces, I presume.
a. You can nominate experts, but do it direct to the AD.
b. Being "allowed" is fine, but you are supposed to give guidance. The point
    is that the knowledge of what is "sane" will disappear over time.

It shouldn't take many words to explain what the intention is.

Cheers,
Adrian