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

[Daniele Ceccarelli <[e-mail]>]

Hi Adrian,

Thanks a lot for the review. 
Please see some comments from my side inline. I’m the one holding the pen but most of your comments are against pieces of text from Lou, hence I’d like to hear from him too.

BR
Daniele  

> 
> From: Teas [mailto:[e-mail]] On Behalf Of Adrian Farrel
> Sent: domenica 26 febbraio 2017 17:05
> To: 'Vishnu Pavan Beeram' <[e-mail]>; [e-mail]
> Subject: Re: [Teas] WG Last Call on draft-ietf-teas-gmpls-scsi
> 
> Pavan, WG,
> 
> I reviewed this document in WG last call as your Technical Advisor.
> 
> There is no reason not to publish this document ahead of the first I-D 
> that will use it, although I might have waited and done it alongside.
> 
> That said, I have some issues that I believe need to be resolved 
> before this I-D can become and RFC. These are nearly all about the 
> IANA section, but that shouldn't be a surprise because the document is 
> not much more than an IANA section :-)
> 
> Thanks,
> Adrian
> 
> ---
> 
> Section 4 has
> 	
>    The Generalized SCSI is used with ISCDs (defined in [RFC4203] and
>    [RFC5307]) of 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.
> 
> This is slightly confusing. RFC 4203 and RFC 5307 define the format of 
> the ISCD for OSPF and ISIS respectively. Those RFCs define ISCDs for 
> PSC, L2SC, TDM, LSC, and FSC.
> 
> You say that the Generalized SCSI is used with ISCDs defined in the 
> referenced RFCs where the switching capability definition references 
> this document. But that is clearly none of them!
> 
> So I think you mean to say something different from what you said.
> 

The part in brackets refers to the ISCD (which is defined in RFC4203 and RFC5307) and not to the Generalized SCSI. 
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."


> ---
> 
> 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.

> 
> ---
> 
> I think Section 6 could be clearer...
> 
> OLD
>        Value       SCSI-TLV                   SwitchCap   Reference
>        ---------   -------------------------- ---------   ---------
>        0           Reserved                               [This ID]
>        1-32768     Unassigned, for use by    [per value]
>                    specific technology                    [This ID]
>        32768-65535 Unassigned, for others    (Any, or
>                                               value list) [This ID] NEW
>    Value       SCSI-TLV                 Switch Type            Reference
>    ---------   -----------------------  --------------------   ---------
>    0           Reserved                 N/A                    [This ID]
>    1-32768     Unassigned, for use by   Value from IANA's
>                specific technology       Switching Types reg.
>    32768-65535 Unassigned, for use by   'Any', or list of
>                multiple technologies     values from IANA's
>                                          Switching Types reg.
> END

Formatting got screwed but I think I got your suggestion. 

> 
> 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. 

> 
> 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) For me it's ok to have a single range. 

> 
> ---
> 
> In section 6
> 
>    New allocation requests to this registry SHALL indicate the value or
>    values to be used in the SwitchCap column.
> 
> I don't believe upper case language has any place in the IANA 
> considerations section. It would be fine to say "must".
> 

OK

> And it s/SwitchCap/Switching Type/
> 

OK

> ---
> 
> 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. 

Registration Procedure(s)
Standards Action for Standards Track documents, Specification Required for other documents

Expert(s)
Daniele Ceccarelli, Fatai Zhang


> 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? 

> From: Teas [mailto:[e-mail]] On Behalf Of Vishnu Pavan 
> Beeram
> Sent: 26 February 2017 00:28
> To: mailto:[e-mail]
> Cc: TEAS WG Chairs
> Subject: [Teas] WG Last Call on draft-ietf-teas-gmpls-scsi
> 
> All,
> This starts a two-week working group last call on
> draft-ietf-teas-gmpls-scsi-01
> 
> The working group last call ends on Mar 11th.
> Please send your comments to the TEAS mailing list.
> 
> Positive comments, e.g., "I've reviewed this document and believe it 
> is ready for publication", are welcome!
> This is useful and important, even from authors.
> 
> Thank you,
> Pavan