Subject: FW: issue 62

From: "Natale, Jonathan" <[email-masked]>
Date: Wed, 2 Oct 2002 15:21:18 -0400

-----Original Message-----
From: Yakov Rekhter [mailto:[email-masked]] 
Sent: Wednesday, October 02, 2002 3:17 PM
To: Natale, Jonathan
Subject: Re: issue 62 

Jonathan,

> Just remove it.

Ok. Could you please repost it to the IDR mailing list.

Thanks.

Yakov.

> 
> "This document deprecates the use of the Authentication
> Information optional parameter [N].
> 
> ...does not need to be added, since this
> will be explained in the "Comparison with RFC1771", right?
> 
> 
> -----Original Message-----
> From: Yakov Rekhter [mailto:[email-masked]] 
> Sent: Wednesday, October 02, 2002 2:50 PM
> To: Natale, Jonathan
> Subject: Re: issue 62 
> 
> Jonathan,
> 
> > agreed
> 
> Do you agree with the first option (removing the text), or with
> the second one (keeping the text, but adding the sentence) ?
> 
> Yakov.
> 
> > 
> > -----Original Message-----
> > From: Yakov Rekhter [mailto:[email-masked]] 
> > Sent: Wednesday, October 02, 2002 12:24 PM
> > To: [email-masked]
> > Subject: issue 62
> > 
> > Folks,
> > 
> >   62) Deprecate BGP Authentication Optional Parameter from RFC1771
> >  
> >
>
----------------------------------------------------------------------------
> >   Status: No Consensus
> >   Change: Potentially
> >   Summary: We are at consensus, in that we agree that we should
deprecate
> >    the BGP Authentication Optional Parameter as described in RFC1771 in
> >    favor of the mechanism described in RFC2385.  We do not have new text
> for
> >    the draft yet, of if we are going to pull the reference entirely.
> > 
> > I would suggest to remove the following text from the draft:
> > 
> >          This document defines the following Optional Parameters:
> > 
> >          a) Authentication Information (Parameter Type 1):
> > 
> > 
> >             This optional parameter may be used to authenticate a BGP
> >             peer. The Parameter Value field contains a 1-octet
> >             Authentication Code followed by a variable length
> >             Authentication Data.
> > 
> >                 0 1 2 3 4 5 6 7 8
> >                 +-+-+-+-+-+-+-+-+
> >                 |  Auth. Code   |
> >                 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >                 |                                                     |
> >                 |              Authentication Data                    |
> >                 |                                                     |
> >                 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> > 
> > 
> >                Authentication Code:
> > 
> >                   This 1-octet unsigned integer indicates the
> >                   authentication mechanism being used. Whenever an
> >                   authentication mechanism is specified for use within
> >                   BGP, three things must be included in the
> >                   specification:
> > 
> >                   - the value of the Authentication Code which indicates
> >                   use of the mechanism,
> >                   - the form and meaning of the Authentication Data, and
> >                   - the algorithm for computing values of Marker fields.
> > 
> >                   Note that a separate authentication mechanism may be
> >                   used in establishing the transport level connection.
> > 
> >                Authentication Data:
> > 
> >                   Authentication Data is a variable length field that is
> >                   interpreted according to the value of the
> >                   Authentication Code field.
> > 
> > If there are objections to this, then I would add the following:
> > 
> >    This document deprecates the use of the Authentication Information
> >    optional parameter.
> > 
> > Yakov.

---

From: Jeffrey Haas <[email-masked]>
Date: Wed, 2 Oct 2002 15:24:37 -0400

> > will be explained in the "Comparison with RFC1771", right?

That is fine so long as we document what the number used to be.
I don't care where it goes.  :-)

-- 
Jeff Haas 
NextHop Technologies