Subject: [ippm] Spencer Dawkins' Discuss on draft-ietf-ippm-ipsec-09: (with DISCUSS)

From: "Spencer Dawkins" <[email-masked]>
Date: Thu, 09 Apr 2015 07:31:58 -0700

Spencer Dawkins has entered the following ballot position for
draft-ietf-ippm-ipsec-09: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
http://datatracker.ietf.org/doc/draft-ietf-ippm-ipsec/

----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

I'm just holding a Discuss so IANA can recheck whatever we end up doing
with the registry conversation (no new actions required).

---

From: Brian Trammell <[email-masked]>
Date: Thu, 9 Apr 2015 16:39:31 +0200

hi Spencer,

Emphatically agreed that the TWAMP-Modes registry at http://www.iana.org/assignments/twamp-parameters/twamp-parameters.xhtml#twamp-modes is very, very weird and should be fixed.

Is the most expedient way to do this in the IANA considerations section of a revised version of this I-D?

Cheers,

Brian

> On 09 Apr 2015, at 16:31, Spencer Dawkins <[email-masked]> wrote:
>

---

From: "MORTON, ALFRED C (AL)" <[email-masked]>
Date: Thu, 9 Apr 2015 10:50:28 -0400

Agree of course, most supporting text could be grabbed from the OWAMP
registry draft and the (revised) initial contents 
of the TWAMP Modes registry should be:

Bit
Posit.  Description          Semantics Def   Reference

0 	Unauthenticated 	  Section 3.1 	  [RFC4656]
1 	Authenticated 	       Section 3.1 	  [RFC4656]
2 	Encrypted 	            Section 3.1 	  [RFC4656]
3 	Unauth. TEST protocol, 
     Encrypted CONTROL 	  Section 3.1 	  [RFC5618]
		
4 	Individual Session 
      Control 	            Section 3.1      [RFC5938]
		
5 	Reflect Octets 
     Capability 	       Section 3.1,     [RFC6038]
		
6 	Symmetrical Size 
     Sender Test Packet Format Section 3.1,  [RFC6038]
7	IPsec                   (this memo)
8-31  Unassigned 		

> -----Original Message-----
> From: ippm [mailto:[email-masked]] On Behalf Of Brian Trammell
> Sent: Thursday, April 09, 2015 10:40 AM
> To: Spencer Dawkins
> Cc: [email-masked]; The IESG; [email-masked]
> Subject: Re: [ippm] Spencer Dawkins' Discuss on draft-ietf-ippm-ipsec-
> 09: (with DISCUSS)
> 
> hi Spencer,
> 
> Emphatically agreed that the TWAMP-Modes registry at
> http://www.iana.org/assignments/twamp-parameters/twamp-
> parameters.xhtml#twamp-modes is very, very weird and should be fixed.
> 
> > email addresses included in the To and CC lines. (Feel free to cut
> > this introductory paragraph, however.)
> >
> >
> > Please refer to
> > http://www.ietf.org/iesg/statement/discuss-criteria.html
> > I'm just holding a Discuss so IANA can recheck whatever we end up
> > doing with the registry conversation (no new actions required).
> >
> >
> >
> >

---

From: Barry Leiba <[email-masked]>
Date: Thu, 9 Apr 2015 11:49:05 -0400

>      Sender Test Packet Format Section 3.1,  [RFC6038]

That way of doing it would work for me.  And, yes, the IANA
Considerations of this document could make that fix.

Barry

---

From: Gregory Mirsky <[email-masked]>
Date: Thu, 9 Apr 2015 17:12:15 +0000

Hi Brian, et. al,
very likely that then this RFC will be the most referenced IPPM RFC, exactly because of it fixing the registry. I can refer to process of fixing IANA MPLS LSP Ping TLVs and sub-TLVs registry that being undertaken in the dedicated draft draft-pac-mpls-lsp-ping-tlvs-and-sub-tlvs-registry.

	Regards,
		Greg

-----Original Message-----
From: ippm [mailto:[email-masked]] On Behalf Of Brian Trammell
Sent: Thursday, April 09, 2015 7:40 AM
To: Spencer Dawkins
Cc: [email-masked]; The IESG; [email-masked]
Subject: Re: [ippm] Spencer Dawkins' Discuss on draft-ietf-ippm-ipsec-09: (with DISCUSS)

hi Spencer,

Cheers,

Brian

---

From: Barry Leiba <[email-masked]>
Date: Thu, 9 Apr 2015 17:01:32 -0400

> very likely that then this RFC will be the most referenced IPPM RFC, exactly
> because of it fixing the registry. I can refer to process of fixing IANA MPLS
> LSP Ping TLVs and sub-TLVs registry that being undertaken in the dedicated
> draft draft-pac-mpls-lsp-ping-tlvs-and-sub-tlvs-registry.

I don't get what the second sentence means, but as to the first sentence:
Actually, I see no reason that the registry needs to point to this
document except as the reference for the new value (decimal 128, bit
7).  The registry itself is still explained in RFC 5938, and no
changes we're talking about making are inconsistent with that.  So I
think the registry itself will retain [RFC5618][RFC5938] as its
references.

Barry

---

From: Gregory Mirsky <[email-masked]>
Date: Thu, 9 Apr 2015 21:20:31 +0000

Hi Barry,
as I understand, Modes being defined by respective RFCs as values, not as bit positions. For example, RFC 4656, Section 3.1 states:
The following Mode values are meaningful: 1 for unauthenticated, 2 for authenticated, and 4 for encrypted.
And RFC 5938 only reflected that in Section 6.4.
Proposed new registry changes how Mode(s) defined in RFC 4656 and RFC 5938. I think that any work that introduces new Mode will have to reference RFC that changes registry format from value to bit position.

	Regards,
		Greg

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Barry Leiba
Sent: Thursday, April 09, 2015 2:02 PM
To: Gregory Mirsky
Cc: Brian Trammell; Spencer Dawkins; [email-masked]; The IESG; [email-masked]
Subject: Re: [ippm] Spencer Dawkins' Discuss on draft-ietf-ippm-ipsec-09: (with DISCUSS)

> very likely that then this RFC will be the most referenced IPPM RFC, 
> exactly because of it fixing the registry. I can refer to process of 
> fixing IANA MPLS LSP Ping TLVs and sub-TLVs registry that being 
> undertaken in the dedicated draft draft-pac-mpls-lsp-ping-tlvs-and-sub-tlvs-registry.

I don't get what the second sentence means, but as to the first sentence:
Actually, I see no reason that the registry needs to point to this document except as the reference for the new value (decimal 128, bit 7).  The registry itself is still explained in RFC 5938, and no changes we're talking about making are inconsistent with that.  So I think the registry itself will retain [RFC5618][RFC5938] as its references.

Barry

---

From: Spencer Dawkins at IETF <[email-masked]>
Date: Mon, 13 Apr 2015 11:21:46 -0500

Hi, Brian,

> >      Sender Test Packet Format Section 3.1,  [RFC6038]

 It would work for me as well.

Spencer