Subject: [trill] Shepherd write-up for draft-ietf-trill-channel-tunnel-06.txt

From: "Susan Hares" <[email-masked]>
Date: Thu, 13 Aug 2015 09:18:36 -0400

Donald, Mohammed, Yizhou, and Trill-WG: 

<document shepherd hat on> 

I have completed my Shepherd review of
draft-ietf-trill-channel-tunnel-06.txt.   Below is the shepherd write-up for
this draft.   I will be uploading the Shepherd write-up today - so please
let me know if you have any questions regarding this write-up.   

Sue Hares

<document shepherd hat off> 

========

Shepherd write-up: 

Status of document: No major errors, minor technical,   3 minor editorial
issues   

Quality of text:  Text provides  clear description of additions.   If you
are re-writing section, it would be useful to rephrase complex sentences in
groups of "less" complex sentences could help the general readability of the
drafts.  

Minor technical issues 

#1 - Bridge Channel Tunnel Protocol = TBD 

My understanding is there is just one RBridge Channel protocol which will be
used for the tunnels: 

An example assignment is in red: 

CSV

Range   Registration Procedures               Note 

0x002-0x0FF       Standards Action              

0x100-0xFF7       RFC Required                     allocation of a single
value

0x100-0xFF7       IESG Approval                   allocation of multiple
values

Protocol               Description                         Reference 

0x000                    Reserved                             [RFC7178]

0x001                    RBridge Channel Error    [RFC7178]

0x002                    BFD Control                        [RFC7175]

0x003                    BFD Echo                             [RFC7175]

0x004                    Tunnel                                  [This RFC] 

0x004-0xFF7       Unassigned        

0xFF8-0xFFE       Reserved for Private Use  [RFC7178]

0xFFF    Reserved                                             [RFC7178]

p. 6  final paragraph reads: 

                "The RBridge Tunnel Channel Protocol Specific Data Fields
are as follows: "

I believe based on figure 2.4 this should be: 

                "The RBridge Channel Tunnel Protocol Specific Data Fields
are the following fields: " 

p. 9 figure 3.1 - Do you want the text in the possible security information
to be changed from: 

from: 

RBridge-channel (0x8946) | CHV=0 | channel Protocol 

to:

RBridge-channel (0x8946) | CHV=0 | Tunnel Protocol = TBD

#2 - Figure 3.3 is unclear

The text states

   A PType of 2 and an initial L2-IS-IS Ethertype indicates that the
   payload of the Tunnel protocol message is an encapsulated TRILL IS-IS
   PDU packet as shown in the figure below. 
 
Please change to 
   A PType of 2 and an initial L2-IS-IS Ethertype indicates that the
   payload of the Tunnel protocol message is an encapsulated TRILL IS-IS
   PDU packet as shown in the figure 3.3.   

The possible security information  has a possible security information with
the following format

                           1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3

       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1

      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      |    RBridge-Channel (0x8946)   | CHV=0 | Tunnel Protocol = TBD |

      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      |          Flags        |  ERR  | SubERR| RESV4 | SType |  0x2  |

      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      |  Possible Security information

      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...

      |  L2-IS-IS (0x22F4)            |

      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      |  0x83     | rest of IS-IS PDU

      +-+-+-+-+-+-+-+-+-+-+-+-+-+-...

IT is unclear how many bytes are between the [L2-IS-IS (0x22F4) and 

[0x83] 

#3 - section 4.2 paragraph 1

The text in this sentence is technically correct, but the complex sentence
makes it difficult to understand: 

   To be more precise, the covered area starts with the byte immediately 
   after the TRILL Header ingress nickname unless the optional flag word
   [rfc7180bis] is present in which case it starts after the flag word,
   and extends to just before the TRILL Data packet link trailer, for
   example just before the FCS for Ethernet.
 
How about: 

   To be more precise, the covered area starts with the byte immediately 
   after the TRILL Header ingress nickname unless the optional flag word
   [rfc7180bis] is present.  If the optional flag word is present, 
   then the covered area starts after the flag word,
   and extends to just before the TRILL Data packet link trailer.  For 
   example, for the Ethernet packet this would be just before the FCS.

---

From: Donald Eastlake <[email-masked]>
Date: Thu, 13 Aug 2015 16:14:28 -0400

Hi Sue,

Thanks for the comments. See below.

On Thu, Aug 13, 2015 at 9:18 AM, Susan Hares <[email-masked]> wrote:

> draft-ietf-trill-channel-tunnel-06.txt.   Below is the shepherd write-up
> for this draft.   I will be uploading the Shepherd write-up today – so
> please let me know if you have any questions regarding this write-up.
>
>
>
> Sue Hares
>
> *Shepherd write-up: *
> groups of “less” complex sentences could help the general readability of
> the drafts.
>
>
>
> *Minor technical issues *
>
>
>
> #1 – Bridge Channel Tunnel Protocol = TBD
>
>
>
> My understanding is there is just one RBridge Channel protocol which will
> be used for the tunnels:
>
>
>
> *Range   Registration Procedures               Note *
>
> *Protocol               Description                         Reference *
>
> 0x000                    Reserved                             [RFC7178]
>
> 0x004                    Tunnel                                  [This
> RFC]

I'm not sure what change, if any, you are suggesting immediately above. In
the IANA Considerations Section, the draft says:

         Protocol   Description    Reference
         --------  --------------  ---------

           TBD     Tunnel Channel   [this document]

>                 “The RBridge Tunnel Channel Protocol Specific Data Fields
> are as follows: “
>
>
>
>                 “The RBridge Channel Tunnel Protocol Specific Data Fields
> are the following fields: “
>

Yes.

> p. 9 figure 3.1 – Do you want the text in the possible security
> information to be changed from:
>
>
>
> from:
>
>
>

Yup, good catch.

> *#2 – Figure 3.3 is unclear*
>
>
>
> The text states
>
>
>
OK.

> The possible security information  has a possible security information
> with the following format
>
>
>

The 0x83 occurs immediately after the 0x22F4. I guess it should be moved to
the end of the previous line although this make the beginning of the "rest
of IS-IS PDU" a bit ragged:

      ...
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |          Flags        |  ERR  | SubERR| RESV4 | SType |  0x2  |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |  Possible Security information
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...
      |  L2-IS-IS (0x22F4)            |     0x83      |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                                    rest of IS-IS PDU
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-...

> #3 – section 4.2 paragraph 1
>
>
>
Sure but how about:

   To be more precise, the covered area starts with the byte
   immediately after the TRILL Header ingress nickname unless the
   optional flag word [rfc7180bis] is present.  If the optional flag
   word is present, then the covered area starts after that flag
   word. In either case, it extends to just before the TRILL Data
   packet link trailer.  For example, for an Ethernet packet it would
   extend to just before the FCS.

Thanks,
Donald
=============================
 Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
 155 Beaver Street, Milford, MA 01757 USA
 [email-masked]

---

From: "Susan Hares" <[email-masked]>
Date: Thu, 13 Aug 2015 16:40:03 -0400

Donald:

All the changes you suggest are fine.  See comments inline below.   Will you be releasing a -07 to resolve these comments? 

Sue 

From: trill [mailto:[email-masked]] On Behalf Of Donald Eastlake
Sent: Thursday, August 13, 2015 4:14 PM
To: Susan Hares
Cc: [email-masked]; Jon Hudson; [email-masked]
Subject: Re: [trill] Shepherd write-up for draft-ietf-trill-channel-tunnel-06.txt

Hi Sue,

I have completed my Shepherd review of draft-ietf-trill-channel-tunnel-06.txt.   Below is the shepherd write-up for this draft.   I will be uploading the Shepherd write-up today – so please let me know if you have any questions regarding this write-up.   

Sue Hares

========

Shepherd write-up: 

Status of document: No major errors, minor technical,   3 minor editorial issues   

Quality of text:  Text provides  clear description of additions.   If you are re-writing section, it would be useful to rephrase complex sentences in groups of “less” complex sentences could help the general readability of the drafts.  

Minor technical issues 

My understanding is there is just one RBridge Channel protocol which will be used for the tunnels: 

CSV

0x100-0xFF7       RFC Required                     allocation of a single value

0x100-0xFF7       IESG Approval                   allocation of multiple values

0x000                    Reserved                             [RFC7178]

0x003                    BFD Echo                             [RFC7175]

0x004                    Tunnel                                  [This RFC] 

0x004-0xFF7       Unassigned        

0xFFF    Reserved                                             [RFC7178]

[Donald] I'm not sure what change, if any, you are suggesting immediately above. In the IANA Considerations Section, the draft says:

[Sue 2]: No changes – just indicating why I think the changes below are necessary. 

                “The RBridge Tunnel Channel Protocol Specific Data Fields are as follows: “

                “The RBridge Channel Tunnel Protocol Specific Data Fields are the following fields: “

Yes.

p. 9 figure 3.1 – Do you want the text in the possible security information to be changed from: 

from: 

to:

Yup, good catch.

#2 – Figure 3.3 is unclear

The text states

Please change to 

OK.

The possible security information  has a possible security information with the following format

      |  L2-IS-IS (0x22F4)            |

[0x83]

The 0x83 occurs immediately after the 0x22F4. I guess it should be moved to the end of the previous line although this make the beginning of the "rest of IS-IS PDU" a bit ragged:

      ...

      |                                    rest of IS-IS PDU

 [Sue]: This resolves my comment 

The text in this sentence is technically correct, but the complex sentence makes it difficult to understand: 

How about: 

Sure but how about:

[Sue 2]: This would be fine. 

Thanks,

Donald

 [email-masked]

---

From: Donald Eastlake <[email-masked]>
Date: Thu, 13 Aug 2015 17:03:47 -0400

On Thu, Aug 13, 2015 at 4:40 PM, Susan Hares <[email-masked]> wrote:

> Donald:
>
>
>
> All the changes you suggest are fine.  See comments inline below.   Will
> you be releasing a -07 to resolve these comments?
>

Sure, I'll post a new version this evening.

Thanks,
Donald

> Sue
>
>
>
> *From:* trill [mailto:[email-masked]] *On Behalf Of *Donald
> Eastlake
> *Sent:* Thursday, August 13, 2015 4:14 PM
> *To:* Susan Hares
> *Cc:* [email-masked]; Jon Hudson; [email-masked]
> *Subject:* Re: [trill] Shepherd write-up for
> draft-ietf-trill-channel-tunnel-06.txt
>
>
>
> Hi Sue,
>
>
>
> [Donald] I'm not sure what change, if any, you are suggesting immediately
> above. In the IANA Considerations Section, the draft says:
>
>
>
> The 0x83 occurs immediately after the 0x22F4. I guess it should be moved
> to the end of the previous line although this make the beginning of the
> "rest of IS-IS PDU" a bit ragged:
>
>
>
>       ...
>

---

From: Donald Eastlake <[email-masked]>
Date: Thu, 13 Aug 2015 18:04:02 -0400

Hi Sue,

Actually I take back one thing I said earlier. See below at <dee3>.

Thanks,
Donald

> RBridge-channel (0x8946) | CHV=0 | Tunnel Protocol = TBD

<dee3> Not really. At first glance, you seemed to be correct and I thought
so but looking at this more closely, what is going on is that you have an
RBridge Channel protocol message nested inside an RBridge Channel Tunnel
message. So looking at figure 3.1, in the first line we have the TBD
RBridge Channel Tunnel protocol number. This is followed by the rest of
that RBridge Channel message header. Then, the nested RBridge Channel
protocol message starts with a 2nd instance of the RBridge Channel
Ethertype. The protocol number for this nested RBridge Channel message
could be any valid RBridge Channel protocol number. I've changed the figure
to look like the following so where it used to say "channel Protocol" it
now says "Nested Channel Protocol" and where it said "Channel Protocol
Specific Data ..." it now says "Nested Channel Protocol Specific Data ...".
Also, this isn't actually data inside the Possible Security Information.
The Possible Security Information is variable length material that is only
present if the SType (Security Type) field is non-zero.

                     1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|    RBridge-Channel (0x8946)   | CHV=0 | Tunnel Protocol = TBD |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|          Flags        |  ERR  | SubERR| RESV4 | SType |  0x2  |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|  Possible Security Information
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|    RBridge-Channel (0x8946)   | CHV=0 |Nested Channel Protocol|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|          Flags        |  ERR  |                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               |
|         Nested Channel Protocol Specific Data ...             /
/                                                               /

---

From: "Susan Hares" <[email-masked]>
Date: Thu, 13 Aug 2015 19:24:04 -0400

Donald: 

One other thing for this draft.  The NITS indicates that RFC 3060 and RFC5869 are informative drafts that you have indicated as normative.   This NIT will cause problems in the IETF review. 

If you intent these two types security algorithms to be utilized, it is important to put something in the security section of the draft that warns people regarding the use of informative drafts. 

872        [RFC3610] - Whiting, D., Housley, R., and N. Ferguson, "Counter with

873              CBC-MAC (CCM)", RFC 3610, September 2003, <http://www.rfc-

874              editor.org/info/rfc3610>.

888        [RFC5869] - Krawczyk, H. and P. Eronen, "HMAC-based Extract-and-
889              Expand Key Derivation Function (HKDF)", RFC 5869, May 2010,
890              <http://www.rfc-editor.org/info/rfc5869>.

Sue 

From: Donald Eastlake [mailto:[email-masked]] 
Sent: Thursday, August 13, 2015 6:04 PM
To: Susan Hares
Cc: [email-masked]; Jon Hudson; [email-masked]
Subject: Re: [trill] Shepherd write-up for draft-ietf-trill-channel-tunnel-06.txt

Hi Sue,

Thanks,
Donald

...

from: 

to:

Yup, good catch.

<dee3> Not really. At first glance, you seemed to be correct and I thought so but looking at this more closely, what is going on is that you have an RBridge Channel protocol message nested inside an RBridge Channel Tunnel message. So looking at figure 3.1, in the first line we have the TBD RBridge Channel Tunnel protocol number. This is followed by the rest of that RBridge Channel message header. Then, the nested RBridge Channel protocol message starts with a 2nd instance of the RBridge Channel Ethertype. The protocol number for this nested RBridge Channel message could be any valid RBridge Channel protocol number. I've changed the figure to look like the following so where it used to say "channel Protocol" it now says "Nested Channel Protocol" and where it said "Channel Protocol Specific Data ..." it now says "Nested Channel Protocol Specific Data ...". Also, this isn't actually data inside the Possible Security Information. The Possible Security Information is variable length material that is only present if the SType (Security Type) field is non-zero.

|          Flags        |  ERR  |                               |

/                                                               /

---

From: "Susan Hares" <[email-masked]>
Date: Thu, 13 Aug 2015 19:25:36 -0400

Donald:

Thanks.  This is why I commented on the text.  I was unsure if it was nested or a mistake.  The revised text below settles this issue for future readers on this comment.   I have sent a comment regarding the use of informative references [RFC3610 and RFC5869].   My opinion is that this use of these informative references as normative is  appropriate.  

Here’s the NITS output 

  ** Downref: Normative reference to an Informational RFC: RFC 3610

  ** Downref: Normative reference to an Informational RFC: RFC 5869

Sue Hares 

From: trill [mailto:[email-masked]] On Behalf Of Donald Eastlake
Sent: Thursday, August 13, 2015 6:04 PM
To: Susan Hares
Cc: [email-masked]; [email-masked]; Jon Hudson
Subject: Re: [trill] Shepherd write-up for draft-ietf-trill-channel-tunnel-06.txt

Hi Sue,

Thanks,
Donald

...

from: 

to:

Yup, good catch.

|          Flags        |  ERR  |                               |

/                                                               /

---

From: Donald Eastlake <[email-masked]>
Date: Thu, 13 Aug 2015 20:44:15 -0400

Hi Sue,

On Thu, Aug 13, 2015 at 7:24 PM, Susan Hares <[email-masked]> wrote:
> Donald:
>
>
> One other thing for this draft.  The NITS indicates that RFC 3060 and
> RFC5869 are informative drafts that you have indicated as normative.   This
> NIT will cause problems in the IETF review.

Well, this needs to be mentioned in the Shepherd review and in the
IETF Last Call but other than that, I don't see why, in this case, it
will cause any problem. It is very common for cryptographic algorithms
to be documented in Informational RFCs because the IETF does not have
change control over them.

> If you intend these two types security algorithms to be utilized, it is
> important to put something in the security section of the draft that warns
> people regarding the use of informative drafts.

I can't recall seeing such language. Can you point to an example? Why
would it matter to anyone implementing the draft?

HMAC is probably the strongest example of such a downref. It is
referenced by 235 RFCs many of which have normative references. See
http://datatracker.ietf.org/doc/rfc2104/referencedby/
I looked at a few of these that are recent and didn't see any explicit
mention of RFC 2104 being Informational. They typically just say
things like "The HMAC authentication mode defined in [RFC2104] is
used."

Thanks,
Donald

> message. So looking at figure 3.1, in the first line we have the TBD RBridge
> Channel Tunnel protocol number. This is followed by the rest of that RBridge
> Channel message header. Then, the nested RBridge Channel protocol message
> starts with a 2nd instance of the RBridge Channel Ethertype. The protocol
> number for this nested RBridge Channel message could be any valid RBridge
> Channel protocol number. I've changed the figure to look like the following
> so where it used to say "channel Protocol" it now says "Nested Channel
> Protocol" and where it said "Channel Protocol Specific Data ..." it now says
> "Nested Channel Protocol Specific Data ...". Also, this isn't actually data
> inside the Possible Security Information. The Possible Security Information
> is variable length material that is only present if the SType (Security
> Type) field is non-zero.
>
>
>

---

From: "Susan Hares" <[email-masked]>
Date: Thu, 13 Aug 2015 21:25:54 -0400

Donald: 

I agree with your viewpoint.  I think the nits detection of the downref issue with these security drafts points to a problem with the automatic review process rather than a real problem.  I have crafted the shepherd report to try to emphasize this fact.   Please review the PROTO write-up to see if you can aid me in this review. 

In listening to the IESG formal sessions, sometimes members of the IESG reviews will focus on the downref issues, and sometimes they do not.  In my shepherd reports, I like to anticipate their normal focus points. 

The output from the general NITS on draft-trill-channel-tunnel-06.  See the warning below. 

Sue 

===========

idnits 2.13.02 

/tmp/draft-ietf-trill-channel-tunnel-06.txt:

  Checking boilerplate required by RFC 5378 and the IETF Trust (see
  http://trustee.ietf.org/license-info):
  ----------------------------------------------------------------------------

     No issues found here.

  Checking nits according to http://www.ietf.org/id-info/1id-guidelines.txt:
  ----------------------------------------------------------------------------

     No issues found here.

  Checking nits according to http://www.ietf.org/id-info/checklist :
  ----------------------------------------------------------------------------

     No issues found here.

  Miscellaneous warnings:
  ----------------------------------------------------------------------------

  -- The document date (June 15, 2015) is 59 days in the past.  Is this
     intentional?
Checking references for intended status: Proposed Standard
  ----------------------------------------------------------------------------

     (See RFCs 3967 and 4897 for information about using normative references
     to lower-maturity documents in RFCs)

  -- Possible downref: Non-RFC (?) normative reference: ref. 'IS-IS'

     Summary: 2 errors (**), 0 flaws (~~), 0 warnings (==), 2 comments (--).

     Run idnits with the --verbose option for more detailed information about
     the items above.

-----Original Message-----
From: trill [mailto:[email-masked]] On Behalf Of Donald Eastlake
Sent: Thursday, August 13, 2015 8:44 PM
To: Susan Hares
Cc: [email-masked]; [email-masked]; Jon Hudson
Subject: Re: [trill] Shepherd write-up for draft-ietf-trill-channel-tunnel-06.txt

Hi Sue,

> NIT will cause problems in the IETF review.

Well, this needs to be mentioned in the Shepherd review and in the IETF Last Call but other than that, I don't see why, in this case, it will cause any problem. It is very common for cryptographic algorithms to be documented in Informational RFCs because the IETF does not have change control over them.

> If you intend these two types security algorithms to be utilized, it 
> is important to put something in the security section of the draft 
> that warns people regarding the use of informative drafts.

I can't recall seeing such language. Can you point to an example? Why would it matter to anyone implementing the draft?

HMAC is probably the strongest example of such a downref. It is referenced by 235 RFCs many of which have normative references. See http://datatracker.ietf.org/doc/rfc2104/referencedby/
I looked at a few of these that are recent and didn't see any explicit mention of RFC 2104 being Informational. They typically just say things like "The HMAC authentication mode defined in [RFC2104] is used."

Thanks,
Donald
=============================
 Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
 155 Beaver Street, Milford, MA 01757 USA  [email-masked]

>  155 Beaver Street, Milford, MA 01757 USA  [email-masked]
>
>
>

_______________________________________________
trill mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/trill