Re: [netmod] IPR Poll on draft-ietf-netmod-yang-semver-09

[Benoit Claise]

No, I'm not aware of any IPR that applies to this draft.

Regards, Benoit



On 1/16/2023 11:59 PM, Kent Watsen wrote:

[NOTE: A response is needed from all listed in this message's "To" line, the 
authors and contributors listed in the draft]


Authors, Contributors, WG,

In preparation for a WGLC Call:

Are you aware of any IPR that applies to drafts identified above?

Please state either:

"No, I'm not aware of any IPR that applies to this draft"
or
"Yes, I'm aware of IPR that applies to this draft"

If so, has this IPR been disclosed in compliance with IETF IPR rules
(see RFCs 3669, 5378 and 8179 for more details)?

If yes to the above, please state either:

"Yes, the IPR has been disclosed in compliance with IETF IPR rules"
or
"No, the IPR has not been disclosed"

If you answer no, please provide any additional details you think
appropriate. If you are listed as a document author or contributor
please answer the above by responding to this email regardless
of whether or not you are aware of any relevant IPR. This
document will not advance to the next stage until a response
has been received from each author.

If you are on the WG email list or attend WG meetings but are not
listed as an author or contributor, we remind you of your obligations
under the IETF IPR rules which encourages you to notify the IETF
if you are aware of IPR of others on an IETF contribution, or to
refrain from participating in any contribution or discussion related
to your undisclosed IPR. For more information, please see the RFCs
listed above and
http://trac.tools.ietf.org/group/iesg/trac/wiki/IntellectualProperty.

Thank you,
Kent and Lou

PS Please include all listed in the headers of this message in your
response.


___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] IPR Poll on draft-ietf-netmod-yang-semver-09

[Jason Sterne (Nokia)]

Hello WG and Chairs,
No, I'm not aware of any IPR that applies to this draft.
Jason

> -Original Message-
> From: Kent Watsen 
> Sent: Monday, January 16, 2023 6:00 PM
> To: netmod@ietf.org
> Cc: Joe Clarke (jclarke) ; Rob Wilton (rwilton)
> ; Reshad Rahman
> ; Balázs Lengyel ; Jason
> Sterne (Nokia) ; Benoit Claise
> 
> Subject: IPR Poll on draft-ietf-netmod-yang-semver-09
> 
> [NOTE: A response is needed from all listed in this message's "To" line, the
> authors and contributors listed in the draft]
> 
> 
> Authors, Contributors, WG,
> 
> In preparation for a WGLC Call:
> 
>   Are you aware of any IPR that applies to drafts identified above?
> 
> Please state either:
> 
>   "No, I'm not aware of any IPR that applies to this draft"
> or
>   "Yes, I'm aware of IPR that applies to this draft"
> 
> If so, has this IPR been disclosed in compliance with IETF IPR rules
> (see RFCs 3669, 5378 and 8179 for more details)?
> 
> If yes to the above, please state either:
> 
>   "Yes, the IPR has been disclosed in compliance with IETF IPR rules"
> or
>   "No, the IPR has not been disclosed"
> 
> If you answer no, please provide any additional details you think
> appropriate. If you are listed as a document author or contributor
> please answer the above by responding to this email regardless
> of whether or not you are aware of any relevant IPR. This
> document will not advance to the next stage until a response
> has been received from each author.
> 
> If you are on the WG email list or attend WG meetings but are not
> listed as an author or contributor, we remind you of your obligations
> under the IETF IPR rules which encourages you to notify the IETF
> if you are aware of IPR of others on an IETF contribution, or to
> refrain from participating in any contribution or discussion related
> to your undisclosed IPR. For more information, please see the RFCs
> listed above and
> http://trac.tools.ietf.org/group/iesg/trac/wiki/IntellectualProperty.
> 
> Thank you,
> Kent and Lou
> 
> PS Please include all listed in the headers of this message in your
> response.

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

[netmod] IPR Poll on draft-ietf-netmod-yang-semver-09

[Kent Watsen]

[NOTE: A response is needed from all listed in this message's "To" line, the 
authors and contributors listed in the draft]


Authors, Contributors, WG,

In preparation for a WGLC Call:

Are you aware of any IPR that applies to drafts identified above?

Please state either:

"No, I'm not aware of any IPR that applies to this draft"
or
"Yes, I'm aware of IPR that applies to this draft"

If so, has this IPR been disclosed in compliance with IETF IPR rules
(see RFCs 3669, 5378 and 8179 for more details)?

If yes to the above, please state either:

"Yes, the IPR has been disclosed in compliance with IETF IPR rules"
or
"No, the IPR has not been disclosed"

If you answer no, please provide any additional details you think
appropriate. If you are listed as a document author or contributor
please answer the above by responding to this email regardless
of whether or not you are aware of any relevant IPR. This 
document will not advance to the next stage until a response
has been received from each author.

If you are on the WG email list or attend WG meetings but are not
listed as an author or contributor, we remind you of your obligations
under the IETF IPR rules which encourages you to notify the IETF 
if you are aware of IPR of others on an IETF contribution, or to
refrain from participating in any contribution or discussion related
to your undisclosed IPR. For more information, please see the RFCs
listed above and
http://trac.tools.ietf.org/group/iesg/trac/wiki/IntellectualProperty.

Thank you,
Kent and Lou

PS Please include all listed in the headers of this message in your
response.
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

[netmod] Regarding IPR on draft-ietf-netmod-yang-module-versioning-08

[Lou Berger]

Authors, Contributors, WG,

In preparation for WG Last Call

Are you aware of any IPR that applies to drafts identified above?

Please state either:

"No, I'm not aware of any IPR that applies to this draft"
or
"Yes, I'm aware of IPR that applies to this draft"

If so, has this IPR been disclosed in compliance with IETF IPR rules
(see RFCs 3669, 5378 and 8179 for more details)?

If yes to the above, please state either:

"Yes, the IPR has been disclosed in compliance with IETF IPR rules"
or
"No, the IPR has not been disclosed"

If you answer no, please provide any additional details you think
appropriate. If you are listed as a document author or contributor
please answer the
above by responding to this email regardless of whether or not you are
aware of any relevant IPR. This document will not advance to the next
stage until a response has been received from each author.

NOTE: THIS APPLIES TO ALL OF YOU LISTED IN THIS MESSAGE'S TO LINES.

If you are on the WG email list or attend WG meetings but are not listed
as an author or contributor, we remind you of your obligations under
the IETF IPR rules which encourages you to notify the IETF if you are
aware of IPR of others on an IETF contribution, or to refrain from
participating in any contribution or discussion related to your
undisclosed IPR. For more information, please see
https://www.ietf.org/standards/ipr/

Thank you,
Lou and Kent

PS Please include all listed in the headers of this message in your
response.


___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] WG adoption call: draft-dbb-netmod-acl-03

[Lou Berger]

Hi,

This poll is closed.  Authors please republish the draft with a 'file 
name' of draft-ietf-netmod-acl-00 and only this and the date changed. 
Please then work to address adoption comments in rev -01.


Thank you,
Lou and Kent


On 12/19/2022 6:00 PM, Lou Berger wrote:

Hello,

This email begins a 3-week adoption poll for:
https://datatracker.ietf.org/doc/draft-dbb-netmod-acl/

Please voice your support or technical objections to adoption on the
list by the end of the day (any time zone) January 9.

This is an extended call due to the holiday/New Year.

Thank you,
Lou (as Co-chair)



___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] Use of unrestricted string in YANG

[Martin Björklund]

Hi,

Italo Busi  wrote:

> BTW, what about using uri for key leafs (see for example RFC8345)?
>
> I think there are other cases where uri could be an appropriate type
> to use for a key …

This is fine if the leaf really is an URI.  Note that no examples in
RFC 8345 have valid uris.  (A uri must have a valid scheme followed by
a ":").  IMO using inet:uri for the keys in RFC 8345 was a mistake.


/martin
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] What to reference when importing an IANA module?

[Randy Presuhn]

Hi -

Serves me right for responding before reading all the messages in
my inbox.  I concur with Benoit's comments.

Randy

On 2023-01-16 2:49 AM, Benoit Claise wrote:

Dear all,

On 1/13/2023 9:22 PM, Randy Presuhn wrote:

Hi -

On 2023-01-13 10:20 AM, Kent Watsen wrote:



On Jan 13, 2023, at 11:25 AM, Benoit Claise 
 wrote:


Hi Tom,
Yes I do think that people outside the IETF may be ignorant of the 
nuances of the way the IETF works and  may not realise that a URL 
to the IANA website must be used in preference to an RFC.  There is 
more to YANG modules than extracting the code from somewhere in 
order to incorporate it into something.  I have even seen RFC 
reference the obsolete list of possibilities  in the RFC that set 
up an IANA registry
If this is the case (And Randy supports this), then we should update 
RFC 8047.


Benoit's reference to RFC 8047 had me puzzled until I saw Kent's
response regarding RFC 8407.  :-)


Agreed - as a hold for document update?

Currently RFC 8407, Section 3.9 says:

    For every import or include statement that appears in a module
    contained in the specification that identifies a module in a 
separate

    document, a corresponding normative reference to that document MUST
    appear in the Normative References section.  The reference MUST
    correspond to the specific module version actually used within the
    specification.


I agree with Kent's "hold for document update" assessment.  The
difficultly with the existing text is that it correctly reflects
the concerns that were at the forefront when it was written -
e.g. making it as easy as possible for developers to get the
necessary context for implementing a module, but, as far as
I can recall, the group hadn't thought as deeply about
registries spun off from an initial document.


Want to take a swing at it?


Not me.  :-)  There are competing requirements, and the "best" answer
will very much depend on each situation.  I think the *spirit* of
the RFC 8407 Section 3.9 is  "point to whatever resource will be most
enlightening to the developer / user."  But the letter of the law is
"point to whatever is needed to generate a tree of normative
reference dependencies" - that is, use what will be most helpful
to the people writing the standards.  There's a point to both kinds of
pointers.

When in doubt, my preference is to go whichever way will make it
harder for implementations to get it wrong.

Agree on the principles, but there is no quick fix.
Look at Med's proposal:

If an IANA-maintained module is imported by another module, a
normative reference with the IANA URL from where to retrieve the
IANA-maintained module SHOULD be included.  Although not encouraged,
referencing the RFC that defines the initial version of the IANA
module is acceptable in specific cases (e.g., the imported version is
specifically the initial version, the RFC includes useful description
about the usage of the module).

If we want to add an IANA link to update RFC 8407, Section 3.9, a couple 
of remarks:

- It's not clear what "a normative reference with the IANA URL" is.
     Is it 
https://www.iana.org/assignments/yang-parameters/yang-parameters.xhtml?
     Or is it 
https://www.iana.org/assignments/yang-parameters/iana-if-t...@2022-08-24.yang?

     The more precise the later, right?
     However, the latter, which is a typical example of IANA maintained 
YANG module does NOT work, as the revision in the URL changes with any 
IAN update
- So this leads to have both RFC and IANA, so 
https://www.iana.org/assignments/yang-parameters/yang-parameters.xhtml + 
RFC7224 (in the above example)
- Also, we should make more generic for some other SDOs, as IANA is for 
IETF only.

   And the guidelines are followed by others: BBF, IEEE, etc.

Regards, Benoit


Randy

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod




___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] What to reference when importing an IANA module?

[Randy Presuhn]

Hi -

On 2023-01-16 12:00 AM, mohamed.boucad...@orange.com wrote:

Hi Randy,

Please see inline.

Cheers,
Med


-Message d'origine-
De : netmod  De la part de Randy Presuhn
Envoyé : vendredi 13 janvier 2023 21:22
À : cc...@ietf.org; netmod@ietf.org
Objet : Re: [netmod] What to reference when importing an IANA
module?

Hi -


...



Want to take a swing at it?


Not me.  :-)  There are competing requirements, and the "best"
answer will very much depend on each situation.  I think the
*spirit* of the RFC 8407 Section 3.9 is  "point to whatever
resource will be most enlightening to the developer / user."  But
the letter of the law is "point to whatever is needed to generate
a tree of normative reference dependencies" - that is, use what
will be most helpful to the people writing the standards.  There's
a point to both kinds of pointers.



[Med] Agree (see my previous answers to Tom). 
https://datatracker.ietf.org/doc/draft-boucadair-netmod-iana-registries/ 
currently says:

If an IANA-maintained module is imported by another module, a
normative reference with the IANA URL from where to retrieve the
IANA-maintained module SHOULD be included.  Although not encouraged,
referencing the RFC that defines the initial version of the IANA
module is acceptable in specific cases (e.g., the imported version is
specifically the initial version, the RFC includes useful description
about the usage of the module).

Would that be OK with you? Thanks


Looks pretty good to me, though when trying to imagine what might
possibly go wrong, I have three minor concerns:

   Is there any way "IANA-maintained module" might be misunderstood to
   include more than the sort of registry-like situations intended here?

   The final parenthetical comment addresses two very different
   situations, and I'm think it's potentially unhelpful to conflate
   them: in the first, the reference is necessary and sufficient to
   identify the normative information needed.  In the second, for
   whatever reasons the information in the module itself is inadequate,
   and an *additional* normative reference is needed.

   This is probably beyond the scope of this I-D, but I'd imagine the
   same issues would exist with type repositories and registries
   maintained by other SDOs or vendors.

Randy

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

[netmod] YANG Versioning agenda Jan 17: Schema Comparison draft

[Jason Sterne (Nokia)]

Hi all,

In the weekly call tomorrow we're moving back to the Schema Comparison draft:
yang-ver-dt/draft-ietf-netmod-yang-semver.txt at master * netmod-wg/yang-ver-dt 
(github.com)

Rgds,
Jason

--
Versioning work on Github:
https://github.com/netmod-wg/yang-ver-dt

--
Weekly webex call details:

Meeting number (access code): 161 096 5630
Meeting password: semver?

Occurs every Tuesday effective Tuesday, November 16, 2021 from 9:00 AM to 10:00 
AM, (UTC-05:00) Eastern Time (US & Canada)
9:00 AM  |  (UTC-05:00) Eastern Time (US & Canada)  |  1 hr

https://ietf.webex.com/ietf/j.php?MTID=me2c6491ebcc37b8127c1244d244d2754
Tap to join from a mobile device (attendees only)
+1-650-479-3208,,1610965630## Call-in toll number (US/Canada)

Jason (he/him)

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] Use of unrestricted string in YANG (was RE: naming scope of a grouping which uses a grouping)

[tom petch]

From: netmod  on behalf of Andy Bierman 

Sent: 13 January 2023 18:31

On Fri, Jan 13, 2023 at 10:10 AM Italo Busi 
mailto:italo.b...@huawei.com>> wrote:
Thanks Andy

I agree with your statement “yang-identifier SHOULD be used instead of string 
for key leafs” and that “yang-identifier is always the most appropriate type to 
use for a key”

The issue is that there are many YANG models either published as RFC or in 
progress which are using string for key leafs. IMHO, it would be better to 
change the type from string to yang-identifier at least in the YANG models 
which are under development


IMO not an issue worth any NBC changes.

I am wondering whether documenting the outcome of this discussion in an I-D, 
updating RFC8407, would be useful to provide clear guidelines to IETF WGs

What do you think?

The appropriate types should be picked during the design process.
It should already be clear that 'pattern' and 'length' are available
to modify the 'string' type.

yang-identifier is too restrictive and 'string' is not restrictive enough.



Yes, that is my view.  When I comment on the use of unrestricted string as a 
key, the author will sometimes ask 'What do I suggest?' and I do not have an 
answer except to refer, regretfully, to the approach taken by SMI, which seemed 
to work well for many years (but which YANG did not follow).

Tom Petch

BTW, what about using uri for key leafs (see for example RFC8345)?

I think there are other cases where uri could be an appropriate type to use for 
a key …


It's just another 'pattern' to check to the YANG compiler.
If 'uri' is appropriate then use it. Same goes for 'uuid'.

Thanks, Italo

Andy


From: Andy Bierman mailto:a...@yumaworks.com>>
Sent: venerdì 13 gennaio 2023 16:17
To: Italo Busi mailto:italo.b...@huawei.com>>
Cc: Jürgen Schönwälder 
mailto:j.schoenwael...@jacobs-university.de>>;
 netmod@ietf.org
Subject: Re: [netmod] Use of unrestricted string in YANG (was RE: naming scope 
of a grouping which uses a grouping)



On Fri, Jan 13, 2023 at 3:32 AM Italo Busi 
mailto:italo.b...@huawei.com>> wrote:
Andy, Carsten, Jürgen, Tom,

Thanks for your feedbacks

If I understand correctly:

  *   Andy, Carsten and Jürgen agree that using unrestricted string for non-key 
attributes makes sense
  *   Andy has a concern only about using unrestricted string for key 
attributes and his proposal is to use the yang-identifier (which does not bound 
the maximum length of the string) instead

Is my understanding correct?

I would say that yang-identifier SHOULD be used instead of string for key leafs.
That does not mean yang-identifier is always the most appropriate type to use 
for a key.

I think that what I have understood would make sense

Any other opinion or suggestion?

Thanks, Italo


Andy


From: Andy Bierman mailto:a...@yumaworks.com>>
Sent: giovedì 12 gennaio 2023 19:24
To: Jürgen Schönwälder 
mailto:j.schoenwael...@jacobs-university.de>>;
 Andy Bierman mailto:a...@yumaworks.com>>; Italo Busi 
mailto:italo.b...@huawei.com>>; 
netmod@ietf.org
Subject: Re: [netmod] Use of unrestricted string in YANG (was RE: naming scope 
of a grouping which uses a grouping)



On Thu, Jan 12, 2023 at 8:33 AM Jürgen Schönwälder 
mailto:j.schoenwael...@jacobs-university.de>>
 wrote:
On Thu, Jan 12, 2023 at 07:08:05AM -0800, Andy Bierman wrote:
>
> Just because the escaped string is "safe" inside a NETCONF protocol message
> does not mean it is safe to use in other tools. Data (especially list keys)
> gets moved
> between software programs. Unrestricted strings increase the risk of data
> injection attacks.
>

Sorry, broken code that does not handle inputs of unexpected length
can't be secured by standardizing arbitrary limits. The only option is
to fix the broken code. Code that fails to validate its inputs can't
be fixed by arbitrary limits and the pure hope that the broken code
will never see something causing it to crash.


My statement is about the risk of using unconstrained values in strings, not 
the length.
It is my preference to avoid characters in leaf keys that are known to cause 
problems
with shells and other tools.

It is a tradeoff. You can have the freedom to construct all-whitespace key 
leafs,
but at the risk of implementations not handling it correctly.  The designer(s) 
should pick the most
appropriate type, based on priorities.

/js

Andy

--
Jürgen Schönwälder  Constructor University Bremen gGmbH
Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103 

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] What to reference when importing an IANA module?

[Benoit Claise]

Dear all,

On 1/13/2023 9:22 PM, Randy Presuhn wrote:

Hi -

On 2023-01-13 10:20 AM, Kent Watsen wrote:



On Jan 13, 2023, at 11:25 AM, Benoit Claise 
 wrote:


Hi Tom,
Yes I do think that people outside the IETF may be ignorant of the 
nuances of the way the IETF works and  may not realise that a URL 
to the IANA website must be used in preference to an RFC.  There is 
more to YANG modules than extracting the code from somewhere in 
order to incorporate it into something.  I have even seen RFC 
reference the obsolete list of possibilities  in the RFC that set 
up an IANA registry
If this is the case (And Randy supports this), then we should update 
RFC 8047.


Benoit's reference to RFC 8047 had me puzzled until I saw Kent's
response regarding RFC 8407.  :-)


Agreed - as a hold for document update?

Currently RFC 8407, Section 3.9 says:

    For every import or include statement that appears in a module
    contained in the specification that identifies a module in a 
separate

    document, a corresponding normative reference to that document MUST
    appear in the Normative References section.  The reference MUST
    correspond to the specific module version actually used within the
    specification.


I agree with Kent's "hold for document update" assessment.  The
difficultly with the existing text is that it correctly reflects
the concerns that were at the forefront when it was written -
e.g. making it as easy as possible for developers to get the
necessary context for implementing a module, but, as far as
I can recall, the group hadn't thought as deeply about
registries spun off from an initial document.


Want to take a swing at it?


Not me.  :-)  There are competing requirements, and the "best" answer
will very much depend on each situation.  I think the *spirit* of
the RFC 8407 Section 3.9 is  "point to whatever resource will be most
enlightening to the developer / user."  But the letter of the law is
"point to whatever is needed to generate a tree of normative
reference dependencies" - that is, use what will be most helpful
to the people writing the standards.  There's a point to both kinds of
pointers.

When in doubt, my preference is to go whichever way will make it
harder for implementations to get it wrong.

Agree on the principles, but there is no quick fix.
Look at Med's proposal:

   If an IANA-maintained module is imported by another module, a
   normative reference with the IANA URL from where to retrieve the
   IANA-maintained module SHOULD be included.  Although not encouraged,
   referencing the RFC that defines the initial version of the IANA
   module is acceptable in specific cases (e.g., the imported version is
   specifically the initial version, the RFC includes useful description
   about the usage of the module).

If we want to add an IANA link to update RFC 8407, Section 3.9, a couple 
of remarks:

- It's not clear what "a normative reference with the IANA URL" is.
    Is it 
https://www.iana.org/assignments/yang-parameters/yang-parameters.xhtml?
    Or is it 
https://www.iana.org/assignments/yang-parameters/iana-if-t...@2022-08-24.yang?

    The more precise the later, right?
    However, the latter, which is a typical example of IANA maintained 
YANG module does NOT work, as the revision in the URL changes with any 
IAN update
- So this leads to have both RFC and IANA, so 
https://www.iana.org/assignments/yang-parameters/yang-parameters.xhtml + 
RFC7224 (in the above example)
- Also, we should make more generic for some other SDOs, as IANA is for 
IETF only.

  And the guidelines are followed by others: BBF, IEEE, etc.

Regards, Benoit


Randy

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] What to reference when importing an IANA module?

[mohamed.boucadair]

Hi Randy, 

Please see inline.

Cheers,
Med

> -Message d'origine-
> De : netmod  De la part de Randy Presuhn
> Envoyé : vendredi 13 janvier 2023 21:22
> À : cc...@ietf.org; netmod@ietf.org
> Objet : Re: [netmod] What to reference when importing an IANA
> module?
> 
> Hi -
> 
...
> 
> > Want to take a swing at it?
> 
> Not me.  :-)  There are competing requirements, and the "best"
> answer will very much depend on each situation.  I think the
> *spirit* of the RFC 8407 Section 3.9 is  "point to whatever
> resource will be most enlightening to the developer / user."  But
> the letter of the law is "point to whatever is needed to generate
> a tree of normative reference dependencies" - that is, use what
> will be most helpful to the people writing the standards.  There's
> a point to both kinds of pointers.
> 

[Med] Agree (see my previous answers to Tom). 
https://datatracker.ietf.org/doc/draft-boucadair-netmod-iana-registries/ 
currently says: 

   If an IANA-maintained module is imported by another module, a
   normative reference with the IANA URL from where to retrieve the
   IANA-maintained module SHOULD be included.  Although not encouraged,
   referencing the RFC that defines the initial version of the IANA
   module is acceptable in specific cases (e.g., the imported version is
   specifically the initial version, the RFC includes useful description
   about the usage of the module).

Would that be OK with you? Thanks

> When in doubt, my preference is to go whichever way will make it
> harder for implementations to get it wrong.
> 
> Randy
> 
> ___
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod

_

Ce message et ses pieces jointes peuvent contenir des informations 
confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce 
message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages 
electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou 
falsifie. Merci.

This message and its attachments may contain confidential or privileged 
information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete 
this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been 
modified, changed or falsified.
Thank you.

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod