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

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

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.
 
---
 
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 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
 
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 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.)
 
---
 
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".
 
And it s/SwitchCap/Switching Type/
 
---
 
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.
 
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.
 
From: Teas [mailto:[e-mail]] On Behalf Of Vishnu Pavan Beeram
Sent: 26 February 2017 00:28
To: [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