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

From: Daniele Ceccarelli <[email-masked]>
Date: Thu, 2 Mar 2017 16:39:19 +0000

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:[email-masked]] On Behalf Of Adrian Farrel
> Sent: domenica 26 febbraio 2017 17:05
> To: 'Vishnu Pavan Beeram' <[email-masked]>; [email-masked]
> 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:[email-masked]] On Behalf Of Vishnu Pavan 
> Beeram
> Sent: 26 February 2017 00:28
> To: mailto:[email-masked]
> 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

---

From: "Adrian Farrel" <[email-masked]>
Date: Thu, 2 Mar 2017 22:36:28 -0000

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

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

> 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

---

From: Daniele Ceccarelli <[email-masked]>
Date: Fri, 3 Mar 2017 10:07:52 +0000

Hi Adrian,

I like the way you cut threads, let me see if I can be as efficient as you've been.

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

Actually I realized that references to RFC4203 and RFC5307 are already in the intro. I dropped the first line.
 
> > > Will you not pre-populate the registry with the TLVs from one of
> > > 7138 and 7688? 
[snip]
> Makes me wonder whether there are any switching types left to make use of

Yours is a good point (even if I'm confident new wonderful switching types will pop up between now and my retirement). I would like to get this document done without any allocation so that value 1 can be allocated for the Availability TLV. 
In order to have other existing switching types use this TLV (and be backward compatible) we need duplicate the switching types for which we want to allow it. If this makes sense and someone is interested in doing it we can welcome new contributions.

[snip]
> Then let's do it and you don't even need to understand my point to make me
OK, done.

[snip]
> 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).

RFC7892 was needed because the allocation policy was Standards Action and we wanted to allocate a code point for and Informational document.
Re-reading RFC5225 I guess you're right, since Specification Required implies Expert Review. From my understanding it also includes Standard Tracks documents.
Designated Experts do not necessarily need to be identified in the draft. When/if the draft will reach the IANA they will ask Deborah who to appoint and she could appoint the TEAS chairs at that point.

Hence, yes I agree with you, I just used Specification Required and removed the DE appointment. 

Thanks a lot once again
Daniele

---

From: "Adrian Farrel" <[email-masked]>
Date: Fri, 3 Mar 2017 14:50:20 -0000

> I like the way you cut threads, let me see if I can be as efficient as you've 
[snip ;-]

> Yours is a good point (even if I'm confident new wonderful switching types will
> pop up between now and my retirement). I would like to get this document done
> without any allocation so that value 1 can be allocated for the Availability TLV.
> In order to have other existing switching types use this TLV (and be backward
> compatible) we need duplicate the switching types for which we want to allow it.
> If this makes sense and someone is interested in doing it we can welcome new
> contributions.

How about talking with the authors of draft-ietf-ccamp-flexible-grid-ospf-ext and the CCAMP/TEAS WG chairs, and the AD?

I don't think there is great urgency to that I-D and it could possibly be pulled back to use the generic TLV space instead of creating its own.

You'd have to act fast and would need the AD to pull on the brake lever.

A

---

From: Fatai Zhang <[email-masked]>
Date: Mon, 13 Mar 2017 03:34:49 +0000

Hi Adrian and Daniele,

Interesting.

I understood the purpose of split ranges is allowing technology specific ones go for the first range "1-32768", and generalized ones go for the second range "32768-65535".

But, the issue raised by Adrian is coming, i.e., one by one technology specific ones go for the first range, and people realize later on that they should be generalized by using the second range.

In addition, "'Any', or list of multiple technologies" is a little confusing, since "Any" includes technology specific.

So, should it explicitly say that technology agnostic( or generic ones) go for the second range?

> > Suppose I define a new TLV for the foo-switch technology. Obviously

> > it comes from the 1-32768 range.

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

> > See my point?

Thanks

Fatai

---

From: Lou Berger <[email-masked]>
Date: Mon, 13 Mar 2017 14:22:37 -0400

How about we just get rid of the ranges? i.e.,

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                  SwitchCap    Reference
       ---------   ------------------------- ---------    ---------
       0           Reserved                               [This ID]
+      1-65535     Unassigned                (value list) [This ID]

Lou

On 3/12/2017 11:34 PM, Fatai Zhang wrote:
>
> Hi Adrian and Daniele,
>
>  
>
> Interesting.
>
>  
>
> I understood the purpose of split ranges is allowing technology
> specific ones go for the first range "1-32768", and generalized ones
> go for the second range "32768-65535".
>
>  
>
> But, the issue raised by Adrian is coming, i.e., one by one technology
> specific ones go for the first range, and people realize later on that
> they should be generalized by using the second range.
>
>  
>
> In addition, "'Any', or list of multiple technologies" is a little
> confusing, since "Any" includes technology specific.
>
>  
>
> > > 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).
>
> _______________________________________________
> Teas mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/teas

---

From: "Adrian Farrel" <[email-masked]>
Date: Mon, 13 Mar 2017 19:46:00 -0000

I think "Any or a list" means that when you create the entry in the registry you
tell IANA
either
- This TLV can be used for any switching type
   (in which case IANA marks the entry as "any")
or
- This TLV can be used for switching types Foo and Bar
  (In which case IANA marks the entry as "Foo, Bar"
 
In the first case, when a new switching type (Humbug) wants to use the TLV, no
change is needed.
In the second case, when a new switching type (Humbug) wants to use the TLV,
IANA has to be requested through Standards Action, and updates the registry
entry to read "Foo, Bar, Humbug"
 
*If* you consider that there will be TLVs that can only be used for one
switching type (MUST NOT or cannot be used for another one) then you could keep
the split. For example, for switching type TDM, you might want a BSOT TLV and
think that no other switching type will ever care about BSOT.  However, I don't
see the point in separating the TLVs when 1 is a special case of n and so a list
with one entry is no harder to understand.
 
Adrian
 
From: Teas [mailto:[email-masked]] On Behalf Of Fatai Zhang
Sent: 13 March 2017 03:35
To: [email-masked]; 'Daniele Ceccarelli'; 'Vishnu Pavan Beeram'; teas@ietf.
org
Subject: [Teas] 答复: WG Last Call on draft-ietf-teas-gmpls-scsi
 
Hi Adrian and Daniele,
 
Interesting. 
 
I understood the purpose of split ranges is allowing technology specific ones go
for the first range "1-32768", and generalized ones go for the second range
"32768-65535".
 
But, the issue raised by Adrian is coming, i.e., one by one technology specific
ones go for the first range, and people realize later on that they should be
generalized by using the second range.
 
In addition, "'Any', or list of multiple technologies" is a little confusing,
since "Any" includes technology specific. 
 
So, should it explicitly say that technology agnostic( or generic ones) go for
the second range?

> technologies, otherwise Foo would get value 1 allocated and Bar would get
32768 allocated ... I don't get the issue.
 
> > 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 not allowed. So a new TLV
must be assigned from the registry (presumably 2).

 
 
Thanks
 
Fatai

---

From: "Adrian Farrel" <[email-masked]>
Date: Mon, 13 Mar 2017 21:06:55 -0000

Sorry all. My post crossed with Lou's.
 
What he says.
 
Adrian
 
From: Lou Berger [mailto:[email-masked]] 
Sent: 13 March 2017 18:23
To: Fatai Zhang; [email-masked]; 'Daniele Ceccarelli'; 'Vishnu Pavan Beeram'; [email-masked]
Subject: Re: [Teas] 答复: WG Last Call on draft-ietf-teas-gmpls-scsi

NEW

Lou
 
Interesting. 

 

 

 
 
Thanks
 
Fatai

---

From: Fatai Zhang <[email-masked]>
Date: Tue, 14 Mar 2017 01:19:58 +0000

Hi Lou,

I agree since it makes the world simpler, ☺

Thanks

Fatai

发件人: Lou Berger [mailto:[email-masked]]
发送时间: 2017年3月14日 2:23
收件人: Fatai Zhang; [email-masked]; 'Daniele Ceccarelli'; 'Vishnu Pavan Beeram'; [email-masked]
主题: Re: [Teas] 答复: WG Last Call on draft-ietf-teas-gmpls-scsi

NEW

Lou

Hi Adrian and Daniele,

Interesting.

Thanks

Fatai

Teas mailing list

[email-masked]<mailto:[email-masked]>

---

From: Daniele Ceccarelli <[email-masked]>
Date: Tue, 14 Mar 2017 08:10:21 +0000

Mmmm didn’t we already agree to remove it some days ago?

https://mailarchive.ietf.org/arch/msg/teas/zsIXhsM6jRHUyE7O5ZwuVUVMRrw

The draft is already update with all the changes discussed with Adrian. I’ve hold the update waiting for further opinions. Now the deadline is gone but I’m happy to see that there is agreement. I’ll post is on Monday of the IETF week.

Thanks
Daniele

From: Fatai Zhang [mailto:[email-masked]]
Sent: martedì 14 marzo 2017 02:20
To: Lou Berger <[email-masked]>; [email-masked]; Daniele Ceccarelli <[email-masked]>; 'Vishnu Pavan Beeram' <[email-masked]>; [email-masked]
Subject: 答复: [Teas] 答复: WG Last Call on draft-ietf-teas-gmpls-scsi

Hi Lou,

Thanks

Fatai

发件人: Lou Berger [mailto:[email-masked]]
发送时间: 2017年3月14日 2:23
收件人: Fatai Zhang; [email-masked]<mailto:[email-masked]>; 'Daniele Ceccarelli'; 'Vishnu Pavan Beeram'; [email-masked]<mailto:[email-masked]>
主题: Re: [Teas] 答复: WG Last Call on draft-ietf-teas-gmpls-scsi

NEW

Lou

Hi Adrian and Daniele,

Interesting.

Thanks

Fatai

Teas mailing list

---

From: Vishnu Pavan Beeram <[email-masked]>
Date: Tue, 14 Mar 2017 08:44:17 -0400

This WG LC is closed.

The authors will publish a new rev (on March 27th) addressing the concerns
raised during the LC.

Regards,
- Pavan

On Sat, Feb 25, 2017 at 7:28 PM, Vishnu Pavan Beeram <[email-masked]>
wrote:

> Positive comments, e.g., "I've reviewed this document and
> believe it is ready for publication", are welcome!