RE: Suggesting Improvements in RFC 1990.

I reiterate my earlier statement that I don't think your proposed
wording changes are significant enough to justify replacing RFC 1990.
However, see my responses inline.

> -----Original Message-----
> From: Hariharasubramanian CS [mailto:[email protected]] 
> Sent: Tuesday, May 23, 2006 8:16 AM
> To: John Bray (bray)
> Cc: [email protected]
> Subject: Re: [Pppext] Suggesting Improvements in RFC 1990.
> 
> 
> 
> On 5/22/06, John Bray (bray) <[email protected]> wrote:
> 
> 
> 
> 	> -----Original Message-----
> 	> From: Hariharasubramanian CS [mailto:[email protected]]
> 	> Sent: Saturday, May 20, 2006 7:08 AM
> 	> To: [email protected] <mailto:[email protected]> 
> 	> Subject: [Pppext] Suggesting Improvements in RFC 1990.
> 	>
> 	> Group,
> 	>
> 	> This is to suggest some improvements in RFC 1990.  There are 3
> 	> corrections. The first
> 	
> 	I believe your first "correction" would just add to the 
> confusion.  It
> 	also contains some unacceptable functional changes.  
> See my comments
> 	below.
> 	
> 	> & the second corrections are for making the 
> 	> points clearer for the reader.
> 	> The third one invites a functional
> 	> change.
> 	
> 	While I don't have major objections to your other two 
> suggestions, I
> 	doubt they are significant enough to justify replacing 
> RFC 1990. 
> 	
> 	>
> 	> Please review.
> 	> Thanks in advance,
> 	> Hariharasubramanian
> 	> NetDevices India Pvt Ltd.
> 	>
> 	>
> 	>                              Suggestion for 
> Improvements in RFC 1990.
> 	>
> 	> Correction 1
> 	>
> 	> Section 2: General Overview Page 4
> 	>
> 	> "The packets to be transmitted using the multilink 
> procedure are
> 	>   encapsulated according to the rules for PPP where 
> the following 
> 	>   options would have been manually configured:
> 	>
> 	>        o  No async control character Map
> 	>        o  No Magic Number
> 	>        o  No Link Quality Monitoring
> 	>        o  Address and Control Field Compression 
> 	>        o  Protocol Field Compression
> 	>        o  No Compound Frames
> 	>        o  No Self-Describing-Padding
> 	>
> 	>   According to the rules specified in RFC 1661, this 
> means that an
> 	>   implementation MUST accept reassembled packets with 
> and without 
> 	>   leading zeroes present in the Protocol Field of the 
> reassembled
> 	>   packet.  Although it is explicitly forbidden below 
> to include the
> 	>   Address and Control fields (usually, the two bytes 
> FF 03) in the 
> 	>   material to be fragmented, it is a good defensive 
> programming
> 	>   practice to accept the packet anyway, ignoring the 
> two bytes if
> 	>   present, as that is what RFC 1661 specifies.
> 	>
> 	>   As a courtesy to implementations that perform 
> better when certain 
> 	>   alignment obtains, it is suggested that a 
> determination be made when
> 	>   a bundle is created on whether to transmit leading zeroes by
> 	>   examining whether PFC has been negotiated on the 
> first link admitted 
> 	>   into a bundle.  This determination should be kept in force
> 	> so long as
> 	>   a bundle persists.
> 	>
> 	>   Of course, individual links are permitted to have 
> different settings
> 	>   for these options.  As described below, member links SHOULD 
> 	> negotiate
> 	>   Self-Describing-Padding, even though pre-fragmented 
> packets MUST NOT
> 	>   be padded.  Since the Protocol Field Compression 
> mode on the member
> 	>   link allows a sending system to include a leading byte of 
> 	> zero or not
> 	>   at its discretion, this is an alternative mechanism 
> for generating
> 	>   even-length packets.
> 	>
> 	>
> 	> I suggest we rewrite this section as:-
> 	>
> 	> The packets to be transmitted using the multilink 
> procedure are 
> 	>  encapsulated according to the rules for PPP where 
> the following
> 	>  options would have been manually configured:
> 	>
> 	>       o  No async control character Map
> 	>        o  No Magic Number
> 	>        o  No Link Quality Monitoring
> 	>        o  Address and Control Field Compression
> 	>        o  Protocol Field Compression
> 	>        o  No Compound Frames
> 	>        o  No Self-Describing-Padding 
> 	>
> 	>   Of course, individual links are permitted to have different
> 	> settings for these options.
> 	>
> 	> 2.1 Address and Control Field Compression:
> 	>
> 	>   This document specifies that Address and Control 
> Field Compression 
> 	> SHOULD BE   used to encapsulate packets using 
> multilink procedures.
> 	
> 	This sentence does not make sense when put together 
> with the next
> 	sentence.  The Address and Control Fields are 
> forbidden, so it does not 
> 	make sense to talk about "Address and Control Field 
> Compression".  The
> 
> 
> 
> [HARI]John, You're mistaken here. When Address and Control 
> Fields (ACF) are forbidden, it means
> that ACF compression is in place. Therefore my suggestion is 
> to explicitly state  "ACFC  is used to
>  encapsulate the material to be fragmented ".

Not quite.  The Address and Control Fields we are discussing are used
for PPP in HDLC-like Framing (RFC 1662).  ACFC as specified in RFC 1661
is optional, meaning that transmitting peers need not omit them even if
the option is negotiated.  The Multilink payload is not using HDLC-like
Framing (it is not a serial interface, it merely emulates one), and the
Address and Control Fields are expressly prohibited.  Talking about ACFC
here just adds to the confusion IMO, and saying "SHOULD" will make
matters worse.  I think the text should simply have said that the
material to be fragmented MUST NOT contain the Address and Control
Fields and left it at that.

> 
>  
> 
> 
> 	use of the word "SHOULD", far from clarifying the text, 
> will just add to 
> 	the confusion.  The FF 03 must be omitted, period.
> 
>  
> 
> 
> 	> This means that it is explicitly forbidden to include 
> the   Address 
> 	> and Control fields (usually, the two bytes FF 03) in 
> the  material to
> 	> be fragmented.. However, It is a good defensive 
> programming  practice
> 	> to accept the packet anyway, ignoring the two bytes 
> if  present, as 
> 	> that is what RFC 1661 specifies.
> 	>
> 	> 2.2 Protocol-Field-Compression
> 	>
> 	>     This document specifies that 
> Protocol-Field-Compression SHOULD BE
> 	> used to encapsulate packets using multilink procedures. it is 
> 	> explicitly forbidden to include the leading zeros in 
> the Protocol
> 	> Field in the material to be fragmented..
> 	
> 	The RFC currently says no such thing, and this would be 
> a significant
> 	functional change if adopted.  As currently worded, the 
> RFC *allows* 
> 	implementations to compress the Protocol Field, but 
> does not require
> 	them to.  It merely *suggests* that PFC be applied if 
> negotiated on the
> 	member links in order to keep the payload on an even 
> boundary, but that 
> 	is not a requirement.  The only requirement is imposed 
> on the receiver,
> 	which must be able to handle packets with or without 
> the leading zero
> 	(as stated below).
> 
> 
>  
> 
> [HARI] IMHO it can stay in the SHOULD clause, as it should 
> generally be followed by all.

That is precisely why it shouldn't say SHOULD.  It *shouldn't*
necessarily be followed by all.  There are often good reasons for *not*
using PFC on the multilink payload.

>  If you see this point as purely optional, then I would 
> change it to  MAY clause
> from SHOULD. 

It *is* purely optional.

> 
>  
> 
> 
> 	> However, according to the
> 	> rules specified in RFC 1661, this means that an   
> implementation MUST 
> 	> accept reassembled packets with and without  leading 
> zeroes present in
> 	> the Protocol Field of the reassembled  packet.
> 	>
> 	> Whether a bundle implements PFC and/or ACFC is 
> dependent upon the
> 	> first link admitted to the bundle. (This means that 
> if the first link 
> 	> negotiates ACFC, then the bundle MUST NOT include 
> Address and Control
> 	> Fields in the material to be fragmented, irrespective 
> of the ACFC mode
> 	> of the other links.) This determination should be 
> kept in force so 
> 	> long as the bundle persists.
> 	
> 	Again, your discussion of ACFC is meaningless, since 
> there are no
> 	Address and Control Fields to compress. 
> 
> 
> 
> [HARI] I think I've already made my point clear. Pl go 
> through this hyperlink. 
>   
> http://www1.ietf.org/mail-archive/web/pppext/current/msg00256.html

I am quite familiar with ACFC, thanks.  Again, omitting these fields
from the packet is optional when ACFC is negotiated with HDLC-like
framing, but it is mandatory when talking about the multilink payload.

> 
> 
>  
> 
> 
> 	 And you are changing the
> 	*suggestion* to apply PFC based on the link setting to 
> a requirement. 
> 	That simply won't fly.
> 
>   
> [HARI] AFAIK, It was difficult for me to get an answer from 
> the RFC for the following question:
> 
>        What is the RFC's stand on how the bundle should 
> choose PFC mode, when the 
>        different member links negotiate different modes for 
> the same PPP parameter ? 
>        (In other words, If there are two links, one 
> negoitiates PFC  and the other doesn't, then which one
>        should the bundle adopt ? ) 
> IMHO we should make some clear statement in the RFC in this 
> regard.    

I don't think the RFC needs to make a clear statement.  It is entirely
an implementation decision, and since the receiving peer must be able to
reassemble and process the packet either way, I don't think it matters.
Trying to specify a precise behavior now will lead to interoperability
problems, because many current implementations will not be in compliance
with the new requirement.

> 
> 
> 
> 
> 	>
> 	> 2.3 Self-Describing Padding
> 	>
> 	>  Member links SHOULD negotiate 
> Self-Describing-Padding, even though 
> 	> pre-fragmented packets MUST NOT be padded. (This 
> means that the
> 	> material to be fragmented MUST NOT contain Pad octets, but the
> 	> fragments themselves SHOULD contain Pad Octets.) 
> Since the Protocol
> 	> Field Compression mode on the member link allows a 
> sending system to
> 	> include a leading byte of zero or not at its 
> discretion, this is an
> 	> alternative mechanism for generating even-length 
> packets. (More 
> 	> details in sec 3.1)
> 	
> 	Actually, if anything, I would prefer the "SHOULD" to 
> be changed to
> 	"MAY".  
> 
> 
> 
> [HARI] Agreed.
> 
> 
> 
> 	I don't think I have ever actually seen SDP applied in
> 	conjunction with multilink. 
> 
> 
> [HARI] But SDP SHOULD be negotiated on each link.

Why?

John

>  
> 
> 
> 	>
> 	> --------------------------------------------------------------
> 	> ------------------------ 
> 	> Correction 2:
> 	>
> 	> Section 3: Packet formats Page 6
> 	>
> 	> "Address & Control and Protocol ID compression
> 	>   are assumed to be in effect. "
> 	>
> 	> I suggest we append  this sentence with "in the material to 
> 	> be fragmented"
> 	
> 	You might want to add "and/or multilink encapsulated" 
> since the packet
> 	is not necessarily fragmented.
> 	
> 	John
> 	
> 	>
> 	> 
> -------------------------------------------------------------- 
> 	> -----------------------------
> 	>
> 	> Correction 3:
> 	>
> 	> Section 5.1.3 Endpoint Discriminator. Page 15
> 	>
> 	>
> 	> "This option is not required for multilink operation. 
>  If a system 
> 	>   does not receive the Multilink MRRU option, but 
> does receive the
> 	>   Endpoint Discriminator Option, and there is no 
> manual configuration
> 	>   providing outside information, the implementation 
> MUST NOT assume 
> 	>   that multilink operation is being requested on this 
> basis alone."
> 	>
> 	> I suggest this paragraph be changed as:
> 	>
> 	>   Endpoint Discriminator option SHOULD BE included 
> for multilink
> 	> operation, to facilitate unambiguous bundle 
> allotment. However, If a
> 	> system does not receive the Multilink MRRU option, 
> but does receive
> 	> the Endpoint Discriminator Option, and there is no manual
> 	> configuration providing outside information, the 
> implementation MUST 
> 	> NOT assume that multilink operation is being 
> requested on this basis
> 	> alone.
> 	>
> 	> But, note that, without Endpoint Discriminator 
> option, in the absence
> 	> of manual configuration, it is possible that, two 
> links of the same 
> 	> peer are connected to links of different peers, 
> resulting in spurious
> 	> behavior.
> 	>
> 	> --------------------------------------------------------------
> 	> -----------------------------
> 	> 
> 	> _______________________________________________
> 	> Pppext mailing list
> 	> [email protected]
> 	> https://www1.ietf.org/mailman/listinfo/pppext 
> 	>
> 	
> 
> 
> 

_______________________________________________
Pppext mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/pppext