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

["Susan Hares" <[e-mail]>]

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'

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

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


     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:[e-mail]] On Behalf Of Donald Eastlake
Sent: Thursday, August 13, 2015 8:44 PM
To: Susan Hares
Cc: [e-mail]; [e-mail]; Jon Hudson
Subject: Re: [trill] Shepherd write-up for draft-ietf-trill-channel-tunnel-06.txt

Hi Sue,

On Thu, Aug 13, 2015 at 7:24 PM, Susan Hares <[e-mail]> 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
=============================
 Donald E. Eastlake 3rd   [phone] (cell)
 155 Beaver Street, Milford, MA 01757 USA  [e-mail]

> 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:[e-mail]]
> Sent: Thursday, August 13, 2015 6:04 PM
> To: Susan Hares
> Cc: [e-mail]; Jon Hudson; 
> [e-mail]
> Subject: Re: [trill] Shepherd write-up for 
> draft-ietf-trill-channel-tunnel-06.txt
>
>
>
> Hi Sue,
>
>
>
> Actually I take back one thing I said earlier. See below at <dee3>.
>
>
> Thanks,
> Donald
> =============================
>  Donald E. Eastlake 3rd   [phone] (cell)
>  155 Beaver Street, Milford, MA 01757 USA  [e-mail]
>
>
>
> On Thu, Aug 13, 2015 at 4:40 PM, Susan Hares <[e-mail]> wrote:
>
> ...
>
>
>
> 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
>
>
>
> 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.
>
>
>
>                      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 ...             /
>
> /                                                               /
>
>

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